[darcs-users] Re: Where Arch is going

[John Goerzen]

On Thu, Jun 02, 2005 at 10:09:00AM -0300, zooko at zooko.com wrote:
> P.S.  A revision control tool is something which works only by interacting
> intimately with one or more skilled humans.  Therefore analysis of the tool
> by itself in the absence of its humans users is inherently a very limited
> predictor of the tool's actual value.  You, John Goerzen, are someone who has
> actually used darcs and arch more than trivially, so I would be interested to
> hear your opinion of baz or bzr, once you actually use one of them.

I tried out baz shortly before switching to darcs, which was, if memory
serves, about 2 months ago.  It had fixed a few of the annoying user
interface things about tla, and it fixed some of its performance
problems.  (tla scales to having lots of patches [where "lots" == more
than 100] very poorly in many cases)

But it didn't really impress me with much new, or anything that would
make its branching and merging better.  Maybe it's better now.  I'll
probably check it out again once they have those darcs-like features.

Arch is well-known for its powerful branching, but I think that's
because it's the first VC to gain attention that can branch across repos
in any sort of sane way.  Darcs branching -- and also merging -- puts it
to shame.  However, I know that the Arch community could make it better
without very drastic changes to their on-disk format, especially where
merging is concerned.

Tom Lord likes to hype the tla star-merge command, but I have found it
to not be very useful, and I'm not the only one with that opinion.  One
case where it falls on its face is if you have a repo A and a repo B,
and patches are being pulled back and forth (cherry picked) between
them.  star-merge doesn't consider excluding patches that are already
present in your tree.  I often used tla replay --skip-present instead of
star-merge.

One other annoyance with Arch merging is that it doesn't preserve full
change history.  Let's say you merge 50 patches from repo A into repo B.
When you commit the change, Arch commits *one* patch to repo B.  It
preserves all the log messages and patch names for the merged patches.
But it does not preserve individual diffs for them.  To get those, you'd
have to go back to repo A.  Worse, it's possible to make changes in repo
B before committing the merge (perhaps to resolve conflicts), so even
looking at those 50 patches may not yield exactly what got committed.
This is one of the key things that makes merging with cherry-picked
changes difficult in Arch, especially when you consider more than 2
branches.

When I last used baz, it hadn't made a significant change to any of
these complaints.

I haven't ever tried bzr.

-- John