X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/c96d672810ae524aedf9ffff08dcca773cd9a876..4fcf25a8200a25a850f095ac90b5ac9f4e395664:/doc/about_rcs_backends.mdwn

diff --git a/doc/about_rcs_backends.mdwn b/doc/about_rcs_backends.mdwn
index 2f0fef0d3..7af4a952e 100644
--- a/doc/about_rcs_backends.mdwn
+++ b/doc/about_rcs_backends.mdwn
@@ -177,3 +177,47 @@ If you have any question or suggestion about the Mercurial backend
 please refer to [Emanuele](http://nerd.ocracy.org/em/)
 
 ## [[tla]]
+
+## rcs
+
+There is a patch that needs a bit of work linked to from [[todo/rcs]].
+
+## [Monotone](http://monotone.ca/)
+
+In normal use, monotone has a local database as well as a workspace/working copy.
+In ikiwiki terms, the local database takes the role of the master repository, and
+the srcdir is the workspace.  As all monotone workspaces point to a default
+database, there is no need to tell ikiwiki explicitly about the "master" database.  It
+will know.
+
+The patch currently supports normal committing and getting the history of the page.
+To understand the parallel commit approach, you need to understand monotone's
+approach to conflicts:
+
+Monotone allows multiple micro-branches in the database.  There is a command,
+`mtn merge`, that takes the heads of all these branches and merges them back together
+(turning the tree of branches into a dag).  Conflicts in monotone (at time of writing)
+need to be resolved interactively during this merge process.
+It is important to note that having multiple heads is not an error condition in a
+monotone database.  This condition will occur in normal use.  In this case
+'update' will choose a head if it can, or complain and tell the user to merge.
+
+For the ikiwiki plugin, the monotone ikiwiki plugin borrows some ideas from the svn ikiwiki plugin.
+On prepedit() we record the revision that this change is based on (I'll refer to this as the prepedit revision).  When the web user
+saves the page, we check if that is still the current revision.  If it is, then we commit.
+If it isn't then we check to see if there were any changes by anyone else to the file
+we're editing while we've been editing (a diff bewteen the prepedit revision and the current rev).
+If there were no changes to the file we're editing then we commit as normal.
+
+It is only if there have been parallel changes to the file we're trying to commit that
+things get hairy.  In this case the current approach is to
+commit the web changes as a branch from the prepedit revision.  This
+will leave the repository with multiple heads.  At this point, all data is saved.
+The system then tries to merge the heads with a merger that will fail if it cannot
+resolve the conflict.  If the merge succeeds then everything is ok.
+
+If that merge failed then there are conflicts.  In this case, the current patch calls
+merge again with a merger that inserts conflict markers.  It commits this new
+revision with conflict markers to the repository.  It then returns the text to the
+user for cleanup.  This is less neat than it could be, in that a conflict marked
+revision gets committed to the repository.