[Pmwiki-users] CVS features was: discussion on line breaks

[Patrick R. Michaud]

On Tue, Aug 12, 2003 at 08:59:05AM -0400, Crisses wrote:
> 
> On Monday, August 11, 2003, at 03:49  AM, Bernhard.Weichel at t-online.de 
> wrote:
> 
> >The lack of "Track Authorship" is IMHO a problem even on pmichaud.com
> >and is also on the way to kill PmWiki for our CVJM application.
> 
> Actually, authorship tracking is *nice* (to me) but not as necessary, I 
> think, as locking pages...I have a love-hate relationship with the idea 
> of locking pages, but how else do you have more than one person edit 
> the same page without messing things up?  has anyone given that thought?

Pm has given it a lot of thought.  :-)  Locking pages, in the traditional
meaning of the term, is actually an incomplete solution, and because of
the way the web works there has to be some mechanism for detecting and
breaking "abandoned locks", which isn't simple (see bottom of this message
for a fuller description).

IMO the correct solution is to merge edits, so that simultaneous edits 
from two or more people are properly merged together, with conflicting 
changes highlighted in some form or fashion.  This is what the concurrent 
versioning system (CVS) does, and many Unix systems come with a merge(1) 
program that could support this.  However, I don't know how widely 
available this program is, and for some reason I've been a bit
reluctant to tie PmWiki to another externally called program (the other
two are diff(1) and patch(1)).  So, I've been holding off on this until
I could decide what to do about getting rid of PmWiki's reliance on
diff/patch.

On the other hand, as I write this now, my reluctance to use merge(1)
seems a bit silly to me--if merge is available, then make use of it to
resolve edit conflicts when they occur, if not, then posts continue to 
work as they always have.

A somewhat less useful approach is to do simultaneous edit detection
as opposed to page locking.  In this approach PmWiki detects when
a simultaneous edit situation has occurred, and then warns the second 
and subsequent simultaneous posters that the document was modified
while they were editing it and gets them to resolve it somehow.
Detecting that two people have simultaneously edited the same page
is almost trivially easy for me to do--I just haven't been able to
come up with "what should happen" when that situation occurs (besides
attempting to merge the edits together via merge(1) as described above).

So, that's where things stand at the moment--if anyone has any comments,
me toos, or suggestions, I'd love to hear them!

==========

What is "page locking" and why it is difficult

The normal meaning of "page locking" with wiki edits is that when 
someone starts editing a page, then other people are not allowed to 
edit the page (the page is "locked") until the original person finishes 
their edits and hits the "submit" button to post their edits back to
the system.

The problem on the web is that the user might never hit the "submit"
button.  There are many ways in which someone could "abandon" the editing 
of a page--hit the "back" button, close their browser, computer or 
network shutdown/failure, etc.--and a script such as PmWiki has no robust 
mechanism for knowing when this has occurred because these events all 
happen without any sort of notification being sent to the server.  So,
when an edit is abandoned, the page on the server remains locked
against further edits, waiting for a post that will never come to
release the lock.

So, to resolve this, we have to come up with a protocol for PmWiki
to decide that a page edit has been abandoned and that the lock can 
be safely released.  Some ideas I've had for this (none of which I'm
particularly fond of):

1. Allow locks to be automatically released after N minutes.  Choosing
a good value for N is tricky here--we want it to be long enough to cover
the amount of time someone might spend in the page edit box.  I think
30 minutes is a practical minimum.  But this approach has some 
drawbacks--if someone clicks "Edit Page", and then immediately hits 
the back button or closes the browser, the page is now locked against edits
for N more minutes.  By storing cookies on the user's browser we could
make it possible for the original editor to get past the lock, but
this requires saving cookies, which some people don't like, and the page
would still be locked to everyone else if someone started to edit a
page but then changed his/her mind.

2. Allow editors to override the lock.  When someone hits "Edit Page"
on a locked page, they get a notification that the page is currently
locked and have the option of continuing the edit even though it is locked.
But I don't like this because it may deter or be confusing to naive
authors, and it may give lots of false signals.

There are other options, but that's what I have thus far.  More
details later.

Pm