Why Darcs users prefer Darcs over Bazaar (was: pbranches style plugin)

[Stephen J. Turnbull]

Ben Finney writes:

 > Perhaps so. It's that discussion about behaviour which leaves me still
 > searching for what's so attractive.

Aha.

 > >  > but its model of changes seems even more intangible than Git and
 > >  > doesn't sound at all attractive.
 > > 
 > > That seems very strange to me.  What could be more tangible than "a
 > > change is a patch"?
 > 
 > "a change is a patch" is not as tangible as "a change is a change in
 > the state of the files themselves".

We understand "tangible" differently, then.  To me "state" is a pretty
abstract thing.[1]

A patch, on the other hand, is something I can print out and hold in
my hand.

 > Patches to content aren't all I care about when tracking a working
 > tree under version control.

I think that's precisely what's attractive to Darcs users.  The Darcs
notion of patch is more general (for example, to remove a file, you
remove the content, then the file, so that's two separate primitive
patches), but basically the idea is that patches are an implementation
of features, an application is a collection of features, and a Darcs
branch simply records that collection in a reproducible way.  The fact
that a particular feature originated in a different branch is
generally not very interesting to Darcs fans.  The order in which
features were developed is generally not very interesting to them,
except when there's a dependency of one patch on another.

 > (For someone who can express exactly what the issue is, I find it
 > odd that you would say "that seems very strange to me" :-)

Ah, I just found your usage of the word "tangible" strange.  No
biggee, I can adapt. :-)

 > Leaving it to algorithmic inference to derive the very thing that I
 > depend on the VCS to track, and not just storing it directly in the
 > revision data, seems like missing the whole point.

Um.  Well, I have to say I have a lot of sympathy with the Darcs
viewpoint.  I do occasionally appreciate the history per se, but
mostly I think of my revision control system as an adjunct to my
editor.  It wasn't until I read Larry McVoy's explanation of why git
(or any other OSS VCS, for that matter) is not considered a threat to
BitMover that I began to appreciate how important history really is in
many applications.  Well, Darcs takes things further in the direction
of historyless-ness than any other OSS VCS.

Maybe it will help to bring this back to the context of looms.  A loom
is a fairly tightly integrated graph of historical and functional
dependencies.  The threads are (AIUI) totally ordered, while the
revisions in each thread are a DAG (micro-branch), that often comes
close to a total order, I bet.  A number of people I really respect as
developers swear by the loom model.  However, if you're a UI-oriented
developer, or maybe a release engineer, you may have a bunch of minor
features in process at any one time (all more or less working for you,
but not quite ready for landing).  Because there are few dependencies
and you don't know the order in which they'll be landed in the public
repo, it doesn't make a lot of sense to impose a lot of structure on
that collection.  (This is the "quilt" or "queue" model.)

The basic ideas of Darcs are (1) track the patches applied at any one
time, so you can apply a collection of patches (a "darcs pull")
without worrying about whether a previously applied patch will
conflict with an attempt to apply it again, and (2) patches know which
other patches they depend on (semantic dependencies that aren't
reflected in syntax have to be added by hand, but they can be
represented in Darcs), and Darcs will insist on pulling them in if you
apply a dependent patch.  This is more or less exactly what you want
for managing a quilt, I think.


Footnotes: 
[1]  You probably don't want to know :-), but to give you an idea, it
usually lives in an abstract space and normally is only apprehended as
an image in another, typically infinite-dimensional, space, injected
there by a random variable which is measurable with respect to certain
Borel fields.