While writing the code for
ReleaseLocksOnSave I kept stumbling across bits and pieces obviously intended to implement the undocumented
delRev
and
repRev
functions. I've personally been using TWiki for nearly 5 years now, and I have
never used either function. The amount of code involved, and the complexity of the code, left me wondering why we support these functions. In order to get my head round the Save and Store code I deleted these functions, and now that it all works, I'm debating putting them back in.
My question for discussion is: can we delete these functions? There are some good reasons for doing so:
- Using these functions strikes me as a bit like Russian Roulette. The risk of getting something wrong seems pretty high.
- These functions effectively hack the CM repository, which most people would agree is a really, really bad idea.
- Existence of these functions adds a lot of complexity/confusion to the code. The implementation is threaded through Save and Store, forcing the use of large numbers of conditionals. It would be OK to implement
delRev
and repRev
as separate CGI scripts, but is it really worth the effort?
- The crunch for me is that neither of these functions would ever be implementable in a smart CM system (e.g. SVN). Such systems rightly forbid the deletion of revisions.
CM repositories retain a revision history for a reason. If revisions should be elided, perhaps because they have offensive or illegal content, then we should do that - elide them, and not delete/replace them, which is like rewriting history. If anyone considers these functions as non-negotiable, essential, I suggest they are implemented as "hack" scripts, and are not published through the web interface.
With all due acknowledgement to the time pressure people are under, I would really value a quick answer on this one; I have
ReleaseLocksOnSave ready to go, apart from this. So please don't wait for someone else to comment first!
--
CrawfordCurrie - 29 Oct 2004
I would say "don't put them back". If some
TwikiAdmin really needs to delete or change revision, he can manually hack the repository.
How can we put a vote here?
--
RafaelAlvarez - 29 Oct 2004
I have used these, as has
PeterThoeny I think, to reverse
WikiSpam - they are quite useful. Not sure how
eliding differs from replacing or removing, but some way of wiping out spam or other really undesirable changes is useful (e.g. what if someone attached illegal porn to a public TWiki?). Intranet TWikis are unlikely to need this often, but companies frequently have strict codes on sexual harassment etc, so being able to reverse changes is important even if seldom used.
CM for software is somewhat different to CM for non-software content, since it's hard to think of a single software change that could be quite so objectionable.
Sounds like the implementation is fairly horrible, but the feature itself is useful. Could perhaps be done as hack scripts if that simplifies matters for the core code, but they should ideally be available via
CGI since not everyone can easily log on to the server (happened to me...)
--
RichardDonkin - 29 Oct 2004
WikiSpam is a current problem for Wikis, e.g. see the comment at end of
SpamProofingOfComments for recent example -
MoinMoin page replaced with 500K of spam links in Wiki format.
BlogSpam is already an issue for
WebLogs - I suggest we look at solutions from that domain and adapt/rewrite as necessary.
WikiSpam does seem quite different to email spam, mainly targetted at improving Google's
PageRank of the spam site.
--
RichardDonkin - 30 Oct 2004
I definitely want to keep them. I use them frequently at TWiki.org (in a responsible manner) mainly in the Main web and Sandbox web to remove inappropriate content (spam, obscene content etc). Also at work we use them to revert content upon request.
TWiki content is not the same as source code, not all of the CM applies.
--
PeterThoeny - 30 Oct 2004
OK, fair enough. I'll put them back as separate
CGI scripts, then, if that's OK with you. That way they can be kept out of the core code and only compiled when needed, rather than on every view, and Apache access controls can be used to protect them as well.
A CM system that can't be banjaxed is important to anyone working on high quality development processes, or anyone in an environment where proof of precedent is important. You really don't want the QA predators to find out your repository can be compromised quite so easily.
--
CrawfordCurrie - 30 Oct 2004
Who will maintain the separate script when TWiki internals change?
--
PeterThoeny - 30 Oct 2004
interesting. We're going to have to remove these when we work on a real versioning store like
SVN, as you simply can't do it (without unloading the dba) so they really have to be a seperate admin script, which uses Store implementation specific interfaces. same thing as with the version number collapsing. the more professional we get with the backend, the less of this kind of thing will be possible in mainline code. (and it really
is an administration task.
--
SvenDowideit - 30 Oct 2004
I think the QA people would also want a way of removing illegal content from an intranet TWiki, and even more so if the content is published to the world (e.g. tech support FAQ database). As long as there's an audit trail of the delRev/repRev, and it's only for administrators, I don't think the QA people would have a problem - virtually every application has a special admin interface for database cleanup.
How about keeping the separate
CGI script idea, but doing the repRev/delRev in such a way they can continue to be maintained, i.e. in a modular fashion, though hopefully with better structure than today. Using .htaccess to control the scripts sounds like a good option, but they are already only available to
TWikiAdminGroup.
Those who use
SVN will have to use separate admin scripts anyway.
--
RichardDonkin - 30 Oct 2004
That's what I was planning, Richard. The maintenance of the separate script should be no different to the maintenance of the internal code. If it is part of the test set, it will be tested. If it is not, it will not, and there will be no motivation to keep it working (as is the case today).
Looking at the code, repRev is exactly the same as delRev followed by a save, so I have only implemented delRev. If there's a reason why repRev is required as well, it's easy enough to implement. The interface is now to take the 'view' url and replace the word 'view' with 'delrev' - this will delete the latest revision of the topic. Existing permissions checks are all retained.
BTW cutting this function out to a separate
CGI script and dropping reprev has saved rather a lot of code.
--
CrawfordCurrie - 30 Oct 2004
Just realized that the repRev
functionality is needed in the core or we would not
AvoidConsecutiveRevisionsBySameUser, e.g. loose the nifty feature of keeping the same revision if the same person saves the a topic again within a one hour windows.
--
PeterThoeny - 30 Oct 2004
This was discussed in
ReleaseLocksOnSave. If you require it brough back, it can be, at the cost of not too much more effort, but it will not be implemented using reprev - there is a much cleaner,
RCS specific, implementation available.
--
CrawfordCurrie - 30 Oct 2004
A problem with the current implementation from the client side perspective
is that
reprev and delrev edits are invisible - not only is the
objectional material completely removed so is the act of that removal.
Recognising that sometimes it is desirable to completely remove material
from all revisions, it should be possible to do so. However a record that
such an edit has taken place, and by whom, should be retained.
Wiki administrators are human, and fallible. On occasion they can, and will,
remove material which, in the interests of the community at large, should
not be completely removed. Users need to have confidence in the revisions.
Once they realise that at any time an administrator can silently remove and
change what they said, their confidence is shaken and the community is
weakened. ((yes I know that anyone with access to the filesystem can do
whatever they like and not leave any trace, but it takes more work than
&cmd=delRev
))
Personally, I would like to not have delrev available at all on my wikis. I
don't want to face the question of whether I have removed material merely
because I had a personal problem with it's nature. I would rather the
history file full of deleted
WikiSpam, so that other can judge for
themselves the censorship decision.
If delRev does exist, it should be difficult enough to use that it will only
be resorted to when absolutely necessary. censorship should not be trivial.
repRev should not exist at all. Replacing a revision should not be possible.
If there is something wrong, it should be replaced with a new revision.
--
MattWilkie - 31 Oct 2004