]> sipb.mit.edu Git - ikiwiki.git/blobdiff - doc/about_rcs_backends.mdwn
web commit by http://ethan.betacantrips.com/: update for 1.42; reformat
[ikiwiki.git] / doc / about_rcs_backends.mdwn
index 8d6c00f9f159a93d28fad109fa10295655318c78..6cc8108a7e2163d21052a28263f5d8a405fb33c3 100644 (file)
@@ -103,7 +103,17 @@ 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
+> 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]]
 
 
 ## [[Git]]