web commit by tschwinge: --usedirs is used by default.

[ikiwiki.git] / doc / about_rcs_backends.mdwn

diff --git a/doc/about_rcs_backends.mdwn b/doc/about_rcs_backends.mdwn
index 84081d6a71c1dcd9e8fc3a0ca8a4c8987a908cf2..079dd1576e5731e310a7c858b947bf7e5b4a651f 100644 (file)
--- a/doc/about_rcs_backends.mdwn
+++ b/doc/about_rcs_backends.mdwn
@@ -29,11 +29,14 @@ see [[commit-internals]].
 
 You browse and web-edit the wiki on W.
 
 
 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
 
 ## [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).
+Schwinge](mailto:tschwinge@gnu.org), although development is on hold curretly.
+There is a patch in [[todo/darcs]].

 
 ### How will it work internally?
 
 
 ### How will it work internally?
 


@@ -102,6 +105,18 @@ by Ikiwiki.
 This approach might be applicable to other distributed VCSs as well, although they're not as oriented
 towards transmitting changes with standalone patch bundles (often by email) as darcs is.
 
 This approach might be applicable to other distributed VCSs as well, although they're not as oriented
 towards transmitting changes with standalone patch bundles (often by email) as darcs is.
 

+> The mercurial plugin seems to just use one repo and edit it directly - is
+> there some reason that's okay there but not for darcs? I agree with tuomov
+> that having just the one repo would be preferable; the point of a dvcs is
+> that there's no difference between one repo and another. I've got a
+> darcs.pm based on mercurial.pm, that's almost usable... --bma
+
+>> 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 [[todo/darcs]], if you submit one that's complete, I will
+>> probably accept it into ikiwiki.. --[[Joey]]
+

 ## [[Git]]
 
 Regarding the Git support, Recai says:
 ## [[Git]]
 
 Regarding the Git support, Recai says:


@@ -161,4 +176,50 @@ CGI operates on M. rcs_commit() will commit directly in M.
 If you have any question or suggestion about the Mercurial backend 
 please refer to [Emanuele](http://nerd.ocracy.org/em/)
 
 If you have any question or suggestion about the Mercurial backend 
 please refer to [Emanuele](http://nerd.ocracy.org/em/)
 

-## [[tla]]
\ No newline at end of file
+## [[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.