[Monotone-devel] Re: wiki in monotone (not at all about disk locality or delta storage)

[Daniel Carosone]

On Fri, Feb 10, 2006 at 07:06:27PM -0500, address@hidden wrote:
> There are some complications.  Each wiki page acts if it where
> its own independent project or branch. 

On Sat, Feb 11, 2006 at 02:35:30AM -0800, Nathaniel Smith wrote:
> The trickiest bit is the making each page independent bit... but you
> can just do that by having each page be a single file named "page.txt"
> in its own branch.  Alternatively, sometimes it is very nice to allow
> renaming in a wiki. 

I didn't immediately see the source of this requirement, but I've now
realised the obvious: it comes from the fact that there are multiple
user sessions in the one wiki server.

However, I don't think it's quite right, either as a requirement or
as a design response.  What I see is a need to keep the user
(editing) sessions separate, rather than the actual pages.  Keeping
the pages separate seems like a backwards way of implying this.

To illustrate:

  Most useful wikis seem to keep session state for each user, even
  anonymous ones; they present tabs of recently visited pages, and
  offer buttons when editing pages to preview and approve, or forget,
  changes.  Yes, some of this state may be implied and kept in the
  page flow and form data being passed back and forth, rather than in
  a server session store, but not all.

  When I start editing a page, most wikis seem to create a lock on
  that page that prevents other users from editing it until i post my
  changes, and there's a timeout on the lock in case I wander away.
  To me, this has always seemed to stem from a limitation of the
  underlying VCS storage (linear history) and the need to prevent
  parallel users overwriting each other's changes, as much as it has
  from UI limitations.

  So, in an early iteration of a hypothetical monotone-based wiki,
  when a user hits edit on a page, we could create a new checkout of
  the head revision in a per-session workspace. They'd do their
  edits, hit save, and trigger a commit.  The underlying VCS no
  longer has a requirement to serialise editing sessions, but we
  still lack a good web-based merge UI, so the wiki still enforces
  its own locking around each page. This ensures that all web-based
  editing heads will merge cleanly, because they only touch different
  files.

  (It might be possible at this point to optimise to using a single
  workspace, and use restrictions to commit only the 'active' file,
  but that's an implementation distraction and prevents some of the
  following).

  The wiki server updates the reader content when new unique heads
  come in, with some logic to stay within its own ancestry train if
  unmergable heads come in via netsync from users outside the per-file
  locking implemented in the web server.  Manual users will have to
  resolve those merges and push again to get their content up on the
  webserver, meanwhile the web-based users continue happily unaware.

  Some more UI work is done, allowing multiple pages to be edited in a
  workspace session, with a separate explicit commit later.  The
  locking is extended so that sessions can lock multiple files, as
  long as the filesets in each session are disjoint.  Now, users can
  rename a page and update the links to that page from other pages,
  and do similar multi-page changes in a single commit that relates
  them together.

  Eventually, a web-based merge UI helper is written, and the file
  locking in the web server can be removed in favour of getting users
  to merge conflicts after commit. It's now also possible for web
  users to help merge revisions that come in via netsync.

  Around about the same time, it also becomes possible to check out
  session workspaces of old revisions and walk around the whole site
  as it existed at the time (rather than just view past versions and
  diffs of individual pages). Perhaps users can edit starting from
  these past revisions, and then merge back to the heads, or even
  create branches.

Now, maybe nobody ever goes to all the trouble to create such a
complete web-based monotone editing frontend, just for a wiki - but
hopefully the point that most of the work is UI issues has been made.

(If one was to go to the trouble, the system produced would be called
a distributed CMS rather than a wiki, and include some other
publishing-related functions to make that effort worthwhile. Such a
system would be very interesting to me indeed... :-)

--
Dan.

pgpkeQQJMSKcv.pgp
Description: PGP signature