[darcs-devel] Darcs performance and stability

Stephen J. Turnbull stephen at xemacs.org
Mon Jun 11 23:51:39 PDT 2007


Samuel A. Falvo II writes:

 > Holy criminey, this is one extremely hard to use tool.

It says right on the label that git is not a tool.  It's a library
implemented as shell commands so that tools can be written as shell
scripts.

Many common tasks are very easy to implement.  For example:

 > If you "git clone" the repository again to another location, the newly
 > updated data was there.  But in the original repository, the web page
 > still showed the old contents!!

To get the effect you want, probably all you need to do is create a
file in the website repo called $GIT_DIR/hooks/post-update, containing

#!/bin/sh
git checkout master

You have every right to want a SCM that does that for you, and many
other things that would *not* be trivial to implement in git.  On the
other hand, git does a lot of things well, and it does almost
everything fast.  With the addition of many convenience commands in
recent versions, it works better for me than Darcs does.

Jason Dagit writes:

 > Samuel A. Falvo II writes:

 > > However, git has something darcs doesn't yet have -- stability and
 > > speed.

 > Given your experience with git I don't understand why you give it
 > points for stability.  Sounds to me like it did the wrong thing plain
 > and simple.  I have a hard time thinking of that as stable.  If I were
 > in your shoes I wouldn't trust git.

No, it didn't do what he thought it would do.  However, what it does
do is accurately documented.  git push updates refs, ie, pointers to
heads of branches.  It is not an inverse to git pull, which *also*
merges the workspace, but rather to git fetch.  Maybe a better name
would be "git deliver".  (Curiously enough, monotone people seem to
think that it is git fetch that is badly named; git pull should be
named git update, and git fetch named git pull.)

If you want to define "trust" as "it almost always does what I want
and expect", that's fine, and will work great for most users.  But
that's a different issue from stability as normally defined, which is
"consistently does what it promises to do and did in the past."

Stability is a problem with Darcs.  Conflicts can (and in my
experience with Darcs up to v1.0.7) often did leave me in a wedged
state, where Darcs would spin indefinitely.  Recovering was often
messy and uncertain, unlike "git reset" (which doesn't affect the
workspace unless you specify "--hard").

Speed is a very big disadvantage for Darcs compared to git or
mercurial.

Nor do I really experience any advantages to patch theory.  In theory,
it's a cool theory.  In practice, "branch early, rebase often" gives
equivalent convenience in git for my use cases.

I still use Darcs for existing small projects, but new ones all end up
in git. :-(

 > I remember reading something a while back about git not always
 > doing the right thing with histories.  Bit of a design problem if I
 > recall correctly.  I think one of the monotone developers pointed
 > this out to me.

Is this related?

http://www.mail-archive.com/monotone-devel@nongnu.org/msg08033.html

If so, there's a long discussion of trust models in the git man page.
Basically, since a version (commit object) hashes the parent's name
and the workspace tree, a single hash can verify the history as well
as the content.  There are admitted weaknesses, but I would call it a
design choice rather than a problem.


More information about the darcs-devel mailing list