Tags:
create new tag
view all tags
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:

  1. Using these functions strikes me as a bit like Russian Roulette. The risk of getting something wrong seems pretty high.
  2. These functions effectively hack the CM repository, which most people would agree is a really, really bad idea.
  3. 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?
  4. 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

Edit | Attach | Watch | Print version | History: r15 < r14 < r13 < r12 < r11 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r15 - 2004-10-31 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.