Why Darcs users prefer Darcs over Bazaar

Stephen J. Turnbull stephen at xemacs.org
Sat Jun 6 17:19:05 BST 2009


Ben Finney writes:

 > Yet a patch, even when printed out, is entirely abstract and worthless
 > without what I'm *actually* interested in: the files affected (including
 > their state). So I see a patch as an abstract representation of changes
 > between tangible states of the files.

But that is *not* what a patch is.  A patch represents an equivalence
class of such changes.  All of the versions of the tree to which the
patch can be applied, paired with of the versions that result after
application.

 > > 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)
 > 
 > "remove the file" isn't something that a patch can represent, so I
 > wasn't aware that they had approriated commonly-understood terminology
 > that way.
 >
 > If all the state that can be tracked in the VCS is to be known by a
 > name, I thought the name "revision" was the consensus, to avoid
 > exactly the fact that a "patch" is aware of only changes representable
 > by the ‘diff -u’ format.
 
You are really literal-minded, aren't you?  (There's nothing wrong
with that, but it certainly imposes a rather high requirement of
precision on your partners in communication.)  To me it's a very
obvious generalization of the terminology.  Cf. makepatch(1) (if you
don't have it installed, check CPAN.)

 > So, you're saying that "a change is a revision"? That doesn't get us
 > any closer to tangibility; it's nearly tautological. My complaint is
 > that the things Darcs tracks are less tangible than those tracked by
 > e.g. Bazaar.

No, a change is not a revision (== version).  (That is the terminology
used by most VCSes, starting with the venerable Revision Control
System, as enshrined in the "-r" flag universally used for specifying
revisions.)  A change is the difference between two revisions.  A
patch (also called a delta) is an object which can be used to execute
the "same change" starting from different revisions.

Of course, the word "patch" is also used to denote the output of
diff(1) and input to patch(1).  The great majority of most patches in
a Darcs repo consists of diff output, so I don't really have a problem
with this loose usage.

 > What do you mean by "features"? My initial guess is that this means
 > "content in a file",

Of course not!  A feature is the subject of a "request for
enhancement".  Eg, it is a behavioral change in an application.  For
some subset of the revisions to which a patch can be successfully
applied, the resulting revision will be changed to include the
feature, i.e., the new behavior.  (Others will crash or otherwise not
successfully implement the feature.)

 > What do you mean by "application"? If you mean "program", that

Yes, that's close enough.  (But it could be, for example, an MPEG or
other data file, and a patch could add frames to a media stream or
observations to a statistical data set.  The latter can probably be
handled by diff/patch, but the former, not.  However, the
generalization from line-oriented diffs to frame-oriented diffs should
not bother you.)

 > doesn't seem to be true in anything except languages where it doesn't
 > much matter where things are written so long as they're written
 > somewhere.

I don't see why you think that would be the case.  A patch can't be
applied just anywhere, nor to just any revision.  Certain
preconditions must be satisfied.  In Darcs, this is called the
"context" of a patch.  In patch(1) this is called context, as well,
but the Darcs concept is richer than just "three lines before and
after the hunk should match, as well as the changed lines".

 > My impression that this is an unattractive and limited view of what is
 > desirable to track in a VCS is certainly being solidified by these
 > illuminations :-)

I'm afraid you're looking at the shadows, not at the light.

 > Where am I going wrong?

You're not going wrong, but you clearly place little importance on the
"high level editor" or "semantic editor" functions that a VCS can
provide.  So your point of view is very different from the Darcs fan's.

 > > 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.
 >
 > I only use looms when I literally want a *series* of patches, each
 > dependent on the previous one. This allows an *externally-imposed*
 > constraint (I need to get these patches submitted and know that they'll
 > each work in series) to be managed by the constraints of a loom.
 > 
 > > 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[...].
 > 
 > Exactly: purposes like that don't make sense for a series-constrained
 > loom, because the external constraint isn't there mandating a
 > series.

Well, Darcs can handle both, although it's more natural for the
latter, "set of independent tasks" setting.  To set up the ordering a
la loom, you will probably need to explicitly add some dependencies of
"high thread" patches on "low thread" patches because there happen not
to be any textual dependencies.  AFAIK that feature is rarely used
except by real experts such as the core Darcs developers; most users
just depend on the heuristic that semantic dependencies are often
accompanied by textual dependencies.

 > Thanks, that at least sheds some more light on it.
 > 
 > It does not, however, do anything to dispel the concern that the default
 > way of applying revisions *loses history*; i.e. I can end up with a
 > branch in which I have as much information as Darcs can give me about
 > that branch, but it's impossible for me to know that the *state* of
 > files at a particular revision is the same as was recorded in that
 > revision initially.

What was that you were saying about hyperbole? :-)

There's only one way to ensure that a particular commit satisfies some
condition: the VCS must test the condition itself, as Aegis does.
Bazaar fails to pass this test as much as any of the other commonly
discussed VCSes, and Darcs probably gets higher marks on it (there's
an explicit configuration option to automatically run the test suite
for every commit).  (Bazaar *chooses* to delegate that function to
PQM, IIRC, so "flunk" is too strong, since it's a design decision.)

As far as reproducing state, the whole point of the theory of patches
is to ensure that reordering the patches *does* indeed leave the
working tree in *exactly the same state*.  You can lose history, yes,
but reproducing state is the sine qua non of a VCS, and Darcs does not
fail on that count.

In order to ensure reproducibility of a given state, in Darcs you
*need* to tag the branch.  But this is just a matter of giving the
state a name, it doesn't add any new information (besides that name)
to the branch; all of the information necessary to reproduce the state
is present in the set of patches.  In fact, a Darcs tag is just a null
commit that depends on all the patches in the branch.

 > In other words, exactly the same problem Linus complained about (in the
 > context of ‘rebase’) with commit messages saying that a particular
 > revision represents a state that has passed specific tests, yet the
 > resulting working tree state was never tested that way because it never
 > existed before.

This is a process problem, not an issue of the VCS *model*.  It's true
that the VCS's *UI* can make it harder to do such things, but even in
Bazaar it's easy enough to script things to "grandfather" the incoming
branch tip's message as the merge commit message.  So it doesn't even
require rebase.

IMO, the right way to handle this problem is to prohibit QA claims in
commit messages (except in Aegis-like systems, where it's
uninformative since all commits have passed the test suite).  Such
claims should be placed in tags.

 > Is this a problem shared by the Darcs model, as I suspect?

Literally taken, yes.  But that doesn't distinguish Darcs from any
other VCS that has the capability of merging a branch but doesn't
enforce passing the test suite as a precondition for recording a
commit, so I don't see why you care. ;-)




More information about the bazaar mailing list