create new tag
, view all tags
This is a summary of an IRC discussion on the locking strategy. It started with the question "Why is the "Release Edit Lock" checkbox not checked by default". A lot of the later discussion is reflected in Support.HowToLockLikeWardWiki

The conclusion of the discussion is that managing the situation where a user hits "back" in the browser after releasing the lock and then saves again can be easily and intelligently managed such that there is no data loss. It is easiest to explain by describing how it would work.

  1. "Edit" passes the browser a hidden field containing the rev number the edit was started on.
    • Minor change to UI/Edit.pm to add <input type="hidden" name="editrev" value="%REVINFO{"$rev"}%">
  2. On preview and/or savemulti, the rev number is checked against the latest rev number.
    1. If it is the latest, the save proceeds as today
    2. If it is different, someone else has saved.
      1. rcsdiff is used to merge the version modified in the editor with the latest version, highlighting conflicts, and generate a new "text". This is then redirected to an alternative preview (using oopsmerge.tmpl) that tells the user what happened i.e. someone else saved in the meantime. This new template should be fairly easy to derive from the preview template. "Your changes to revision 1.xx were merged with changes made in the meantime by AnotherUser".

With this approach, there would be no need to retain an edit lock after closing an edit. Also, no more problems with the "back" button.

-- CrawfordCurrie, SvenDowideit, WillNorris - 25 Jul 2004

This is a brilliant idea smile For non techies it is easier then Ward's Wiki or current TWiki.

It can be made smart for one special case: If there is a conflict at the very end one can assume that both users appended text. This can be handled programmatically.

-- PeterThoeny - 25 Jul 2004

One nasty wrinkle is the risk of race conditions. The race occurs between the version check and the actual save; this has to be made atomic somehow, The .lock file can be recast into the role of a race-lock.

-- CrawfordCurrie - 05 Aug 2004

One possible spoiler for this is html forms that direct save to a topic and CommentPlugin forms (which don't save to the topic they appear on). They would not pass the revision variable. CommentPlugin could be rewritten to pass the revision but you will always have the problem with forms.

-- SamHasler - 15 Sep 2004

HTML forms that direct save to a topic? Can you give an example?

-- CrawfordCurrie - 18 Sep 2004

SaveContentWithoutEdit was added for cario. I think the only place it is used on twiki.org is CategoryCategory, although the DiscussionForumAddOn uses it (see Sandbox.DiscussionForum) and there is also a demo I created: Sandbox.ManageRedirects. There was a bug in cairo with SaveNotHonoringOnlynewtopicFlag but this is now fixed, although not yet on twiki.org.

-- SamHasler - 19 Sep 2004

OK, I see what you mean, I think. Any save that replaces the entire topic content has to acknowledge the risk that another save of the entire topic text occurred in the interim. If only a fragment of the topic is being changed (e.g. a form field) or content is being added (as in comments) that it should be safe enough to overwrite old topic content.

At this stage it's too much to rdiff form fields; though of course if forms were stored sensibly and we were working on a model that didn't differentiate between topic text and text stored in forms, it would naturally fall out. But we're not, so it won't.

-- CrawfordCurrie - 19 Sep 2004

As "Any save that replaces the entire topic content has to acknowledge the risk that another save of the entire topic text occurred in the interim", could we instead queue only the piece that needs to be appended?

The queuing infrastructure (shared by mailer contrib) would then insert only the changed bit into the right place when the topic becomes available.

-- MartinCleaver - 19 Sep 2004

Now that I think about it I think that's the way it works. Direct Save would normally be creating a new topic (CategoryCategory, DiscussionForumAddOn), or using the topic itself as a template to modify the forms (No examples on TWiki.org but I've done this myself) or a separate template to overwrite the content anyway (as in the case of ManageRedirects).

The problem is not that direct save causes confilcts. It's that it won't pass the revision as described above. So any solution would have to allow saving without passing the revision parameter and in that case it should be able to safely overwrite.

-- SamHasler - 20 Sep 2004

Yes, correct. That's handled by clause 2.2.1 in the description above. The merge should probably be silent in all cases.

-- CrawfordCurrie - 20 Sep 2004

but how would it know it's different if direct save doesn't pass it the revision number?

-- SamHasler - 20 Sep 2004

It would always be treated as different.

-- CrawfordCurrie - 26 Sep 2004

That kind of defeats the purpose of direct save forms.

I think in most cases where the revision parameter is missing and the onlynewtopic flag is not set it would be safe to overwrite without bothering the users with a preview step.

-- SamHasler - 28 Sep 2004

Normally I would agree, but I'm a wee bit nervous about large text boxes in forms - which some people do use - which should really get treated in the same way as the topic text. I'm starting to think that we have to Diff the form fields. Using Algorithm::Diff that shouldn't be too hard.

-- CrawfordCurrie - 29 Sep 2004

Would it make sense to add <input type="hidden" name="editrev" value="%REVINFO{"$rev" topic="targettopic"}%"> to html forms?

-- SamHasler - 29 Sep 2004

CrawfordCurrie said in ForceNewRevisionCheckBox "It would be better to spend the effort doing ReleaseLocksOnSave which would create a revision for every edit. This is scheduled for DakarRelease."

Is it correct that this would force a separate revision on subsequent saves by the same user? I don't see any reason why it should.

I'd much prefer that ForceNewRevisionCheckBox was also implemented.

-- SamHasler - 12 Oct 2004

Yes, that's correct. That is conventional CM practice - a revision for every change. Preumably you don't like this because you think it would generate too many revisions, especially on checkpoint saves?

Can we have the architects reading on this, please, Peter? Do we need to collapse adjacent revisions by the same user, and if so, within what time window? I don't know what would be involved in making it collapse adjacent changes, perhaps the existing code is re-usable.

-- CrawfordCurrie - 23 Oct 2004

i'd prefer that we don't expect twiki to collapse revisions or anything like this. its not going to be possible to implement on revision systems like SVN.

-- SvenDowideit - 24 Oct 2004

I now agree. I just thought of a time where being able to see every revision would have helped me out :). However I wouldn't normally want to see every trivial revision by the same author. Perhaps rdiff needs a collapse=sameauthor url parameter that would merge previous revisions by the same author within a configurable time period. I'd also like to see a history page for topics showing every diff and allowing direct comparisons beween any two revisions using a collapse=all parameter.

Aside: Thinking of SubversionAsStore makes me wonder how it would handle removing offensive content from a revision.

-- SamHasler - 24 Oct 2004

Removing any content is non-PC, offensive or otherwise. Rewriting the history books is an activity normally reserved to the elite in totalitarian states

-- CrawfordCurrie - 25 Oct 2004

I'm thinking of public internet sites where there could be a legal requirement to do so, even in revisions.

-- SamHasler - 25 Oct 2004

in that catastropic case i'd advise exporting the SVN dba, editing the export file and then re-importing. legal requirement issues should be sufficiently rare to hopefully not need coded support in twiki.

-- SvenDowideit - 26 Oct 2004

The working model is now that topic locks are used for atomic save operations. If a topic is locked, it is locked for a maximum of 1 minute. After that time, anyone can break the lock. save now blocks on the availability of the lock. As a result, the "delete obsolete locks" functionality in the mailnotify script is now itself obsolete.

-- CrawfordCurrie - 29 Oct 2004

AvoidConsecutiveRevisionsBySameUser needs to be retained, this is a useful and unique feature of TWiki. That topic also shows reasons why "common CM practices" do not map directly to CM.

-- PeterThoeny - 31 Oct 2004

The imlementation needs to be merged across to DEVELOP, which has diverged from the codebase used. I hope to do that in the next few days.

-- CrawfordCurrie - 11 Jan 2005

Done. Rev 3526.

-- CrawfordCurrie - 17 Jan 2005

checked TWiki web changes into DEVELOP r3594

-- WillNorris - 04 Feb 2005

Edit | Attach | Watch | Print version | History: r49 < r48 < r47 < r46 < r45 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r49 - 2005-04-22 - WillNorris
  • 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-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.