+
+## 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.