[darcs-users] Subversion vs DARCS (was: Moving sf.net CVS to cryptomonkey.net Subversion)

[David Roundy]

On Sun, Jul 06, 2003 at 11:00:46AM -0400, Zooko wrote:
> 
> [This message has four sections and a conclusion.]
> [Myers wrote the lines prepended with "> ".  I wrote the lines prepended 
> with "> > ".]
> [Cc:'ing the darcs mailing list.]

Hello!

> Section 1: sysadmin evaluation of Subversion
> 
> > As a sysadmin I'm *really* happy with subversion.
> 
> Good to know!  I think Subversion is less stable than CVS, and that could
> give us problems, but it might be worth the risk of using Subversion
> instead of CVS in order to have convenience and security for the server
> admin.

I should mention that sysadminning a darcs repository may be a bit of a
pain.  In particular, I haven't much tested the repo installing and
creating tools, so I can't really claim they are stable.  On the other
hand, I'd be happy to work with you to fix any bugs that you discover.

Also, in my opinion darcs' way of doing things is relatively simple which
should make at least some things a bit easier.  At least I tried to keep it
simple.  The only catch is that to create a "pushable" repository (which
you would want) you need a user for each pushable repository (or branch).
What you gain from this is that you can have the patcher run a test script
on each set of patches and reject them if it fails, and the normal UNIX
permissions keep people from trashing the server (unless you have a local
exploit open).

> Section 2: DARCS transport, frequency of merge conflicts
> 
> > DARCS looks intresting.  I can't tell from the docs
> > 
> > http://abridgegame.org/darcs/manual/node3.html#SECTION00330000000000000000
> > 
> > if you can commit changes via HTTP, or only via email.  Only via email
> > is bad if your outgoing mailserver takes forever to deliver messages.
> > You could be waiting for your email to go thru while some conflicting
> > patch gets commited first.
> 
> I don't think this would be a problem.  Real merge conflicts are rare,
> and would be even rarer using DARCS.  For example, DARCS has a "token
> replacement" kind of patch in addition to the normal "hunk was changed"
> kind of patch, so if I rename some variables at the same time as you are
> changing the way those variables are used, it won't conflict.
>
> And when there *is* a merge conflict, it isn't a big disaster if the
> patch that got committed first is the one that reaches the repository
> second.  Because we're going to merge the two patches so that they are
> both accepted, and the order in which they arrive makes no difference to
> whether they will merge correctly or how they will be merged.  (But it
> might make a difference to *who* merges them.  :-))
> 
> But if it *were* a problem, I think it wouldn't be too hard to switch the
> transport from e-mail to scp or something.

Well, it certainly could be annoying.  The order in which the patches are
applied doesn't matter, but someone would have to resolve the conflict
(assuming there is one, and they aren't *that* uncommon.

Committing by scp could be managed, but I'd rather not do that.  I guess
one could do something as simple as scping the patch bundle itself... that
wouldn't be bad... Hmmmm.  I like the email method because it should be
readily extendable to do things like maintaining mirrors (or branches that
should get all patches to head) by simple forwarding of the email.

> Section 4: why DARCS is speeecial
> 
> The magical features of DARCS are enabled by the fact that it doesn't
> consider a file to be a sequence of bytes, but instead to be a collection
> of all of the patches that have ever been applied to that file.
> 
> Section 4.a: conflict management at the level of patches instead of
> branches
> 
> Therefore, if there is a merge conflict, DARCS doesn't say "this branch
> changed line 200 in a different way than that branch changed line 200".
> It says "this patch from this branch conflicts with that patch from that
> branch", even if the patches were committed many days ago onto their
> respective branches.
> 
> Basically, DARCS shows you the conflict at the level of patches (which
> specific patch from branch A conflicted with which specific patch from
> branch B), where Subversion shows you the conflict at the level of
> branches (treating all of the patches that have gone into branch A as a
> single huge patch, it conflicts with the single huge patch made up of all
> of the patches that have gone into branch B).
>
> Section 4.b: cherry-picking of patches
> 
> Furthermore, DARCS allows you to "cherry-pick" patches.  Suppose you are
> reading the mnet-cvs list, and you see a bugfix patch go by that you
> think should be applied to your branch.  You try to apply it.  With
> either CVS, Subversion or DARCS, if the patch applies cleanly then you
> are done.  (Although as I mentioned DARCS has a more nuanced notion of
> diffs which allows more patches to apply cleanly than does Subversion.)
> 
> With either CVS, Subversion or DARCS, if the patch *doesn't* apply
> cleanly, then you get an error message.  With CVS and Subversion, the
> error message is based on the text.  It is the familiar "merge conflict"
> error message that we've all seen with CVS -- the one that shows the two
> different changes separated by "<<<<<<<" and ">>>>>>>".
> 
> With DARCS, the error message is based on the patch history.  It says
> "this bugfix patch that you pulled can't be applied to your branch,
> because it depends on the XYZ refactoring patch, which was applied to the
> other branch but not to your branch".

I think this section is just a little overly optimistic.  It is true that
darcs won't let you pull a patch that depends on another patch (which might
in some other systems show up as a merge conflict).  However, currently
when you have an ordinary conflict darcs doesn't notate which patches
actually caused that conflict.  This could be done, I just haven't done it.
Normally darcs will just give you a conflict marker basically like the
"<<<<<<<" and ">>>>>>>" of CVS.

I would love to create a graphical merge tool that would give you all sorts
of interesting options, but currently the state of haskell GUI libraries is
a bit discouraging.  I probably will start with creating an interactive
text merge tool, but even that is a relatively low priority.

> Conclusion:
> 
> Bottom line: DARCS promises some delicious features that no other Free
> Software revision control system has even conceived of, as far as I am
> aware [3].  However, I haven't tried it yet, and there could well be
> hassles of administration, UI, or stability that would render it
> unusable.  I want to find out.

There will certainly be hassles of administration, I'm just not sure if
they will render it unsuable for you.  I certainly would love to get any
bug reports you could provide me with.  The UI at least I am happy with,
and I've gotten a number of user requests, so it's already improved a fair
amount.  As far as "crashing" stability goes, it's fine.  It is very good
when it comes to danger of losing your archive data, since everyone who
uses a repo has a complete copy of that repository (of course, this comes
at a cost in terms of disk space).  The only other stability issue is that
of backwards compatability (i.e. can new versions of darcs read the old
repo format).  This tends to be pretty good.

One thing that occurred to me that you might not have considered is that
darcs hasn't been ported to windows.  I took a look at mnet but didn't
immediately see if it ran on windows.  Darcs could certainly be ported to
windows (and maybe even without too much work), but I'm not going to do it,
as I don't have windows.  It does run on MacOS X, though.
-- 
David Roundy
http://www.abridgegame.org