Re: [Monotone-devel] Re: ikiwiki and monotone

[Daniel Carosone]

This is based on reading and speculation so far, not yet on usage
experience.

On Wed, Oct 11, 2006 at 05:20:51PM +0100, Bruce Stephens wrote:
> address@hidden writes:
> 
> [...]
> 
> > If it were to use monotone, and asked to display a page that had
> > multiple heads, how should it proceed?  Give the user a choice of
> > versions?  Display a graph of all possible versions?  Merge them on
> > the spot?  Present a variorum edition?

It understands that some of the underlying RCS plugins will be for a
dvcs.  For page edits done via the webserver cgi rather than
"externally", it understands that rather than doing locking, such
edits might be parallel and might create conflicts that need to be
merged.  It has a UI for the user to resolve such merges (basically,
it puts cvs-like conflict markers in the page content, and asks the
user to reedit the page).

I'm not sure it understands that multiple heads might arrive over the
network unmerged - ie, without involving a local edit via the cgi.

Regardless, its up to the plugin to decide how to handle this.  For
darcs, there's a discussion about allowing each edit cgi to record the
starting version and submit patches against that, rather than having
multiple web users run out of the same workspace.  

I think a monotone driver could work similarly, letting monotone see
the correct ancestor of each page edit and thus also see the real
editing concurrency between users for merging.  My first suggestion at
an implementation would be to use mtn cat to retrieve the file
contents at the start of an edit, recording the base rev.  If a form
arrives back with edits, then check out a workspace at the base
revision, drop in the edits, commit, merge.  Perhaps with the
enhancements for cvsync.refactor that allow workspace-less commits via
automate, we can even avoid the checkout.

> Well, hypothetically it could try to merge them, and if they merged
> cleanly could present that.  Otherwise it could present a page
> pointing at both.
> 
> I'm not too sure that's all that interesting, though: don't you run
> ikiwiki in order to produce static HTML?  In which case it could just
> abort and require you to merge?

Correct. In either case, whether run directly or triggered via the
cgi, the regeneration is done in a workspace.  If a merge failed, the
build workspace won't be updated to incorporate the conflicting
changes until someone resolves the conflict and pushes a merge.

While some web ui for this might be nice, probably with the assistance
of a PageHistory link to a viewmtn instance, its not a major concern
for me personally.  I'm far more interested in being able to resolve
the merge away from the web ui.  

Besides, depending on your specific purposes, for some wiki's not
updating public pages until conflicting edits are resolved by an
expert may be exactly what you want.

Consider a 'moderated' page flag: rather than blocking out web edits
of 'important' pages entirely as some wiki's do, allow web users to
submit edits as extra heads (into a review branch?) and then have
admins approve/merge them back to the public content later.

--
Dan.

pgpI8kdaHZhof.pgp
Description: PGP signature