]> sipb.mit.edu Git - ikiwiki.git/blobdiff - doc/about_rcs_backends.mdwn
web commit by tuomov
[ikiwiki.git] / doc / about_rcs_backends.mdwn
index 95d641e726dc4161a43ac69a2f55314794f27d44..6cc8108a7e2163d21052a28263f5d8a405fb33c3 100644 (file)
@@ -33,7 +33,8 @@ You browse and web-edit the wiki on W.
 ## [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 the [[patchqueue]].
 
 ### How will it work internally?
 
 
 ### How will it work internally?
 
@@ -102,6 +103,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 the [[patchqueue]], 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:
@@ -117,7 +130,20 @@ part).  GIT doesn't have a similar functionality like 'svn merge -rOLD:NEW
 FILE' (please see the relevant comment in mergepast for more details), so I
 had to invent an ugly hack just for the purpose.
 
 FILE' (please see the relevant comment in mergepast for more details), so I
 had to invent an ugly hack just for the purpose.
 
-## [Mercurial](http://www.selenic.com/mercurial/)
+By design, Git backend uses a "master-clone" repository pair approach in contrast
+to the single repository approach (here, _clone_ may be considered as the working
+copy of a fictious web user).  Even though a single repository implementation is
+possible, it somewhat increases the code complexity of backend (I couldn't figure
+out a uniform method which doesn't depend on the prefered repository model, yet).
+By exploiting the fact that the master repo and _web user_'s repo (`srcdir`) are all
+on the same local machine, I suggest to create the latter with the "`git clone -l -s`"
+command to save disk space.
+
+Note that, as a rule of thumb, you should always put the rcs wrapper (`post-update`)
+into the master repository (`.git/hooks/`) as can be noticed in the Git wrappers of
+the sample [[ikiwiki.setup]].
+
+## [[Mercurial]]
 
 The Mercurial backend is still in a early phase, so it may not be mature 
 enough, but it should be simple to understand and use.
 
 The Mercurial backend is still in a early phase, so it may not be mature 
 enough, but it should be simple to understand and use.
@@ -146,4 +172,6 @@ in the destination directory each time 'hg update' is called.
 CGI operates on M. rcs_commit() will commit directly in M.
 
 If you have any question or suggestion about the Mercurial backend 
 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/).
+please refer to [Emanuele](http://nerd.ocracy.org/em/)
+
+## [[tla]]