[darcs-users] use case showing DARCS's unique features?

[David Roundy]

On Tue, Jun 24, 2003 at 06:30:14PM -0400, Zooko wrote:
> 
> I'm looking for a new revision control system to replace CVS.  I've put up a 
> web page detailing what I've learned so far:
> 
> http://zooko.com/revision_control_quick_ref.html

Looks pretty accurate (at least as far as darcs goes, I can't vouch for the
others).

You mention that the manual says it's "a little slow on large projects",
and alas that is still true.  However, since I wrote that I have speed
darcs up by perhaps a factor of ten, so progress is being made, and I am
hopeful.  Actually, I think there may have been a speed regression
recently, at least for the linux kernel, which is my test case of a large
project.  Lazy languages sure can make it tough to track down efficiency
problems.

> I've read the manual.  I really like the basic theory of patches (patches
> are invertible, they are dependent iff they don't commute, and "parallel"
> patches can always be merged).  Actually I'm not sure I like that third
> part.

Well, the third is necesary in order to have a repo be completely defined
by its set of patches... well you could do without it, but then some
branches would be unmergeable, which doesn't sound any good...

> Anyway, although I like the mathemtical abstraction of the basic theory
> of patches, I don't understand how such an abstraction would actually be
> used in a tool, and I definitely don't understand what DARCS can actually
> do in practice that arch or Meta-CVS cannot.
> 
> Could someone please show me the simplest text file and the simplest
> branch and merge that I might actually want to do in practice, and that
> DARCS facilitate where arch or Meta-CVS would complicate?

I don't know anything about Meta-CVS, but arch I do know about.  Imagine
the following scenario:

Patch A: add file foo to repo
B: modify file foo
C: modify file bar (already existing before this scenario starts)

Now in a separate repo (lacking both A and B) if I want to pull patch B,
darcs will not allow this unless you also agree to pull patch A.  patch C,
however, can be pulled without pulling either A or B.  This is just a
consequence of the commutation properties in darcs.

In arch, however, you could pull either patch B or C without pulling A.  If
you pull B (without A) you'll get some sort of a weird conflict result (I'm
not sure what, but you could experiment and see--probably you'd get at best
a hard to understand .rej file created by patch(1)).  This is because arch
has no way of knowing that B depends on A.

There are, of course, other differences as well, but this is the first that
comes to mind (and probably one of the likelier ones in practice).  I guess
it would be better to have an example with a real merge in it, but that
takes more thought.
-- 
David Roundy
http://www.abridgegame.org