Tags:
create new tag
, view all tags
A problem with alternative implementations of Store using other CM providers is that we lose the rather nice "change merging" capability. This lets an author go back into a topic they just edited and make e.g. spelling or grammar corrections without creating a new revision to the topic. The advantages of this are obvious. The functionality that does this is known as repRev and has been a bone of contention for some time.

The problem is that most CM systems quite rightly don't permit you to delete or modify existing revisions. Once a topic is under revision control, it is under control, and any change - even by the same author - will increment the revision number.

However, there is way to rationalise the "TWiki model" with the "CM system model", and that is to queue changes, but not commit them until either another person wants to edit, or the timelock expires.

It's easy to envisage an implementation that uses the existing .lock file as a timelock on a topic.

  • If you want to edit and a .lock file exists:
    • If it isn't yours, then commit (ci) the changes before editing.
    • If it is yours, then make the changes to the topic and reset the timelock.
  • If no lock exists, make changes to the working file as now and create a .lock, but don't commit the change.
  • A cron job, or a subprocess launched by the view script, could check for existing timed-out locks and commit the changes.

Main.MartinCleaver suggested this in ReleaseLocksOnSave some time ago, but it's taken me this long to understand what he meant. (There is more on what I meant at AppendTextToTopic... - MC)

-- CrawfordCurrie - 10 Nov 2004

Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r3 - 2005-02-18 - MattWilkie
 
  • 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-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.