One users changes can trash anothers

Test case

Do This

---

1. Get one user to edit a page and keep it at the edit page
2. Get another to make some changes (Use Edit Anyway) and submit them
3. Get the 1st user to make changes and check them in

This Happens

---

The 2nd users changes are lost. They are in the version history though!

I think this should happen

---

When the 1st user checks in a merge and prompt for any clashes should occur. Version controls tools handle joint editing by either banning it or doing a merge. The previous version of both edits can be determined so a 3 way merge should be possible.

Without this behaviour and with the 60 min timeout (whats that all about - surely the submit point is known) it is very hard to feel confident in using the system.

Environment

TWiki version:	01-Sep-2001 Release
TWiki plugins:	default
Server OS:	?
Web server:	?
Perl version:	?
Client OS:	NT 4
Web Browser:	IE 5.50 128bit

-- StephenLee - 10 Jan 2002

This is the current spec, deliberately breaking the lock will hide the changes of the first user.

I changed the classification to FeatureEnhancementRequest.

-- PeterThoeny - 17 Feb 2002

A much more severe version of this problem is:

1. Get one user to edit a page and keep it at the edit page
2. Have that user do nothing for 60 minutes
3. Get another to make some changes (no lock exists now, as it timed out) and submit them
4. Get the 1st user to make changes and check them in

Now the changes from the 2nd user are lost too, but neither of the two users ever had a chance to avert the problem. At our TWiki (which is only used by people who all sit close together), we have been bitten by that problem a few times, and have changed the lock timeout to 7 days instead of 60 minutes, thus forcing people to either release their locks, or to pick up the phone and call the other person.

The same occurs (although I did not test this) if one person opens the same page in two browsers (without regard to any lock timeout, of course).

I don't think it's really necessary to do a 3-way merge, but I think a warning at save time would be necessary; especially as people could also just go "back" in their browser to get to an edit page without any lock intervention at all, currently.

For an implementation of such a warning, I guess it would be sufficient to track the timestamp of the ,v file - as the version is not changed if the same person edits a file, tracking the version would maybe not enough (but if it should turn out to be easier to do, it would certainly be better than no warning at all).

EDIT 24 Sep: Together with the auto-unlock feature, this actually works good, see below.

TODO: refactor

-- EkkehardKraemer - 19 Sep 2002

With this new info it seems to me this is now both a bug, or at least a prominent warning in the install docs, and a request.

Without this behaviour and with the 60 min timeout (whats that all about - surely the submit point is known)

Yes the submit point is known but the lock remaining after a save allows one to: edit, save, edit more, save,... and only store one version number in RCS. This is why there is an explicit "release edit lock".

-- MattWilkie - 19 Sep 2002

Yes, but this usage is not the standard one. Moreover I think then you are basically doing a "checkpoint", and thus the "checkpoint" feature should be directly provided (as in KoalaSkin), but it should not be the default!

Otherwise, people leave the lock unknowingly, and it can become tempting to override the lock with all the potential problems it brings, if you are too often faced with forgotten locks.

I will try to code a plugin to tackle this "overrwriting saves". We could even merge the diffs a la CVS.

-- ColasNahaboo - 20 Sep 2002

The problem I described at 19 Sep actually can be solved very nicely like this:

• Set the lock timeout to 7 days or whatever (very long)
• Enable the auto-unlock feature in WebPreferences
• Beat your users into not using the back button in the browser and not breaking locks
  • trying to get users to not the back button will be a hard fight. The second most used feature of browsers is the back button. The first? Hyperlinks.[0] -- MattWilkie

This way, pages are automatically locked exactly between "edit" and "save", and nothing bad can happen. You lose the "locked after edit" feature, but that's ok if everyone remembers to press "Edit" later, and not go back in the browser.

Of course, a CVS merge would be nice, too, ColasNahaboo!

-- EkkehardKraemer - 24 Sep 2002

this has been done in DevelopBranch; what to do with this page now?? (how to mark it as done and/or duplicate?)

-- WillNorris - 02 Mar 2005