X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/32be1324a904ebe97e1a3336be9e6fd05be92a69..69065b8e79cce13648db711ed1fefaf6f41713fd:/doc/about_rcs_backends.mdwn?ds=inline

diff --git a/doc/about_rcs_backends.mdwn b/doc/about_rcs_backends.mdwn
index c20fa5cc3..7af4a952e 100644
--- a/doc/about_rcs_backends.mdwn
+++ b/doc/about_rcs_backends.mdwn
@@ -36,7 +36,7 @@ W "belongs" to ikiwiki and should not be edited directly.
 
 Support for using darcs as a backend is being worked on by [Thomas
 Schwinge](mailto:tschwinge@gnu.org), although development is on hold curretly.
-There is a patch in the [[patchqueue]].
+There is a patch in [[todo/darcs]].
 
 ### How will it work internally?
 
@@ -114,7 +114,7 @@ towards transmitting changes with standalone patch bundles (often by email) as d
 >> IMHO it comes down to whatever works well for a given RCS. Seems like
 >> the darcs approach _could_ be done with most any distributed system, but
 >> it might be overkill for some (or all?) While there is the incomplete darcs
->> plugin in the [[patchqueue]], if you submit one that's complete, I will
+>> plugin in [[todo/darcs]], if you submit one that's complete, I will
 >> probably accept it into ikiwiki.. --[[Joey]]
 
 ## [[Git]]
@@ -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.