2 people editing one page.

[Paso]

Hi team,

I did many searches on forums about this, as I would of thought this would of already been asked but couldn't find so apologise for double threading if so.

In short - if 2 people are editing the same page the person that saves the page last overwrites the first persons changes (even if different sections are changed). and when reviewing recent changes it does not even show what the first person had saved,

We have a large organization which indeed this may happen on more then one occasion. is there a way to lock a page so only one person can edit at a time. ?

Many thanks for any advice

[royk]

Hey there Paco,

There isn't an easy technical solution for maintaining a session between client and server to make locking work correctly - at best, we'd be doing an ad-hoc implementation (and doing things like auto-expiring locks, which would defeat the purpose if an editor is taking a long time to edit). Because of this, we've opted not to pursue the lock as a solution for conflict errors.

Right now, when the second person overwrites, they are given a notice about them overwriting the changes; they are then linked to the diff page, where they are responsible for merging the changes back in. It's possible that the recent change log could pick up a notice about this in its comment.

Addressing a better merge strategy (especially for disparate sections, like you mentioned), is something we want to look into for an upcoming release.

If you have any other ideas about an alternate merge/conflict resolution strategy, we're all ears

[Paso]

thanks for your info RoyK.

appreciate the response your team provides. we shall let you know if any idea's arrive.

[Petrus4]

If you have any other ideas about an alternate merge/conflict resolution strategy, we're all ears

Hi Roy, I have written about this before and here are my current thoughts about page merging and a possible alternate merge/conflict strategy.

First off I believe SteveB mentioned not wanting to lock a page since this would cause problems with users not being able to access a page until an admin releases it. I can see that from a perspective of large groups using Deki Wiki as in the Wik.is site and hosted versions (open to the internet) of deki Wiki you would not want to have this capability.

When deki Wiki is used in a corporate or school environment, behind a firewall and open to say 60 employees, the locking of page should not cause this problem. Corporate/ school users are used to having excel or word documents locked when another user with edit rights to a document is editing the document. The user then gets a message stating: "user so and so is editing this document, please ask the user to close the document." Also in my environment (school) 3 or 4 teachers will try to edit the same page during the same time (3 pm when classs are over or at lunch time) They get very frustrated when they have to merge data especially in their already tight schedules.

So here is one alternate merge/conflict resolution that I found on the web:

From the PBWiki Forum:

We finally have got reasonable page locking in place. If you click "Edit" on a page and nobody else was editing that page, you've got a "lock" on the page. If someone else comes by to edit (and has permissions to do so), then they'll get an error that will explain that you're currently editing the page and have a lock on it. If 15 minutes or more go by without the user submitting the new content (and thus releasing their lock), other editors will have permission to "steal" their lock. This keeps one editor from locking out everyone else either intentionally or by accident. The original editor will not be able to post their content if someone else submitted a replacement in the interim; they will have to manually merge in their changes. While not ideal, it's not anticipated that lock-stealing will be common, so it doesn't seem likely to me that this issue (manual merging) will come up often. With a group wiki, however, it *was* often the case that multiple editors would step on each other's toes and that, thankfully, should now be solved.

Wikimatrix.org describes it here: page locking is not advised unless locking is timed.

A brute-force solution is to make sure only one person can edit a page at one time by using page locks and thus avoid conflicts. Because of the statelessness of the HTTP protocol locking pages is not efficient or indeed wise in any way. Locking must be timed or else manual system administrator intervention will be needed to release locks (since a user may start editing and simply close the window without releasing the lock, either on purpose or by accident).

Here something I see happening at my school: from: goland.org

I see this on Wiki's all the time where different people will take ownership of a particular section of the page. People also tend to be pretty good at talking to each other so that pervasive changes are handled via a mutual agreement that everyone else will stay out until the person making the changes says o.k. Of course all these mechanisms are really just informal locks. And that makes sense. Humans understand exclusivity, locks make intuitive sense, so if the system (for good performance and other reasons) won't provide locking the users will figure out their own way to implement locks, even if informally.

our users have set up schedules to edit the same page on the wiki at scheduled times so that there are no conflicts. They get too confused by the conflict resolution page and would rather set up "informal locks" than face a merge/conflict message.

Here Are two possible merge/conflict strategies:

STRATEGY 1
OK so I would strongly reccommend (request) this opton:

1. Page locking would be automatic. The user would have an exclusive lock.
2. The lock would be released when the user cancels or hits the save button.
3. IF a lock is more than X minutes old, say 15 minutes, another user can steal the lock.
4. If the lock is more than X time old, say 1 hour.. the lock is removed automatically.

STRATEGY 2

This stragey would use the diff merge process I believe is already used in Deki wiki with an added feature:

The user is automatically shown the page where his/her changes are shown in green and the previous users changes are shown in red and each change is shown with a radio button so that the current user can check which changes he/she wants to keep and leave those changes that he/she does not want to keep unchecked. This would make the process much more userfriendly imo.

note: I wrote that "the user is automatically shown" the merge page, since I think it is clear that if there is a mergeconflict the user would want it to be resolved, and would not want to copy over the previous users edits.

[Paso]

STRATEGY 1
OK so I would strongly reccommend (request) this opton:

1. Page locking would be automatic. The user would have an exclusive lock.
2. The lock would be released when the user cancels or hits the save button.
3. IF a lock is more than X minutes old, say 15 minutes, another user can steal the lock.
4. If the lock is more than X time old, say 1 hour.. the lock is removed automatically.


I certainly like this idea. in our organization this would largely benefit us. as we will have over 400 users.

[SteveB]

We now have a merge feature that is being tested. Most wiki engines uses wikitext, which makes mergine a lot simpler. Deki Wiki uses XML all the way. This made handling merging a lot harder.

However, I think there is a good chance that the mechanism we are now testing will work well enough to make it into the next release (1.8.3).

What does this mean to you? Well, it means that unless 2+ users happen to edit the same "words" or "words" next to each other, the engine will automatically merge the changes from these users. That include formatting, tables, links, etc. If changes do conflict, we will continue to give preference to the latest change and show the warning that something was overwritten.

This approach is a great compromise, in my opinion. First, it covers the 95% case where changes don't conflict. Second, it doesn't rely a "lock out" process which makes it impossible to collaborate on content simultaneously. Also, as you saw in PBWiki's description, if the lock times out, the author will need to manually merge. That sucks if you're working on a large edit and just happen to have run down your clock (phone call, long email, updating your facebook profile, name-your-favorite-time-sink-here).

The beauty of automatic merging with conflict detection, is that it isn't a black-and-white process. Instead, only changes that were conflicting will be at risk. Everything else, where there was no conflict will be resolved. So, in the end, although you may have edited 20 words and your colleague edited 30, only 3 where lost because of a conflict. However, since you'll be presented with the warning and the "show differences" link, it will be very easy for you to spot what those words were.

Anyhow, keeping my fingers crossed that the new merge algorithm works well enough to go into 1.8.3!

[Petrus4]

STRATEGY 2

This stragey would use the diff merge process I believe is already used in Deki wiki with an added feature:

The user is automatically shown the page where his/her changes are shown in green and the previous users changes are shown in red and each change is shown with a radio button so that the current user can check which changes he/she wants to keep and leave those changes that he/she does not want to keep unchecked. This would make the process much more userfriendly imo.

note: I wrote that "the user is automatically shown" the merge page, since I think it is clear that if there is a mergeconflict the user would want it to be resolved, and would not want to copy over the previous users edits.

Steve, that sounds like a great feature to have a merge scenario that works like you wrote! What do think about about Strategy 2 above?

[SteveB]

Providing an interactive mode for custom resolution of merge conflicts would be awesome. This is something we'd definitively like to do in the future.

[Petrus4]

I am feeling really frustrated about the page merge stituation, which does not seem to working correclty now.

In our situation we have tables that get updated by our staff at about the same time. They are used to using documents on a shared drive to do this, and it this scenario the document would be locked if another person is editing it.

Is there any way I can change some code to allow for locking? I would like to use this until the new merge mechanism is released. That would make me really


How are things coming along for the new merge mechanism released in 1.8.3?