]> sipb.mit.edu Git - ikiwiki.git/blobdiff - doc/about_rcs_backends.mdwn
web commit by tschwinge: --usedirs is used by default.
[ikiwiki.git] / doc / about_rcs_backends.mdwn
index 6cc8108a7e2163d21052a28263f5d8a405fb33c3..079dd1576e5731e310a7c858b947bf7e5b4a651f 100644 (file)
@@ -29,12 +29,14 @@ see [[commit-internals]].
 
 You browse and web-edit the wiki on W.
 
+W "belongs" to ikiwiki and should not be edited directly.
+
 
 ## [darcs](http://darcs.net/) (not yet included)
 
 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?
 
@@ -112,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]]
@@ -175,3 +177,49 @@ 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/)
+
+There is a patch in [[bugs/Monotone_rcs_support]].  It works, but its conflict handling is a little ugly.
+
+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.  (BTW - this is also true of subversion.  It might be possible to simplify the svn config?)
+
+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.