Why Darcs users prefer Darcs over Bazaar

[Ben Finney]

"Stephen J. Turnbull" <stephen at xemacs.org> writes:

> 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 the fact that you have to explain that “patch” doesn't mean
what anyone unfamiliar with Darcs but experienced with Unix programming
would expect it to mean, says a lot about the gap in explanation of a
phrase like “a change is a patch”.

> You are really literal-minded, aren't you?

I had pre-existing definitions of words that didn't match what you were
telling me about them, so needed clarification on what exactly we're
talking about. I don't think that makes me especially literal-minded.

> (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.)

I don't have that installed, and the fact that it's not already
installed on my system as a dependency of some other development tool
speaks a fair bit to where the burden of explanation is on this usage of
the term “patch”.

Again, not that there's anything wrong with that; it just means that “a
change is a patch” can't be expected to be understood without often
going down this little cul-de-sac, so I wonder why the Darcs terminology
doesn't use some term not already loaded with specific implications of
the type of data that does or does not meet the definition.

>  > 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.

Okay, this is now the third time that I though I understood what you
were saying but now have to conclude I don't. So a Darcs change, the
atomic unit of data to be represented, is a delta between two other
deltas between file states, yes?

Recall that this discussion of terminology all started with your claim
that “a change is a patch” roots Darcs in very tangible atomic units.
Yet I find it to be astonishingly intangible compared to the concept of
“working tree state” which is the atomic unit I *actually* want tracked
by a VCS. Have I misunderstood?

>  > 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.

I place a lot of importance on editing semantics, but that's what my
editing tools are for. How does Darcs help me to edit semantics?

>  > 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.

That's not the issue. The VCS doesn't make the claim, the person who
wrote the commit message makes that claim. Since they had full access to
the state of the working tree when committing, it's reasonable to expect
that they believe that claim to be true.

The above statement is about the *user* being unable to know whether the
commit message refers to anything tangible that they can *themselves*
verify whether that commit message's claims are true.

> 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.

I find myself less reassured by an algorithmic *inference* of state from
changes-between-changes-between-state, than by storing a lower level of
abstraction from that state. Based on the focus we've found in this
discussion, that seems to be close to the core of my
I-don't-see-the-benefit.

> 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.

So why isn't this done every time I commit, so that I don't need to know
in advance which particular state I will want to reproduce? Isn't that
decision being made every single time I commit with a commit message?
Why do I need to also choose a name for each state or risk being unable
to reproduce it?

I suppose all the above questions are also asking, what am I buying with
this cost that I don't have to pay when using Bazaar? Why would I ever
want to commit *without* being able to ensure I can reproduce state?

> 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.

In a VCS which *can* ensure reproducibility of the state represented in
any commit, I don't have to make that choice every time I commit. I
*can* make such claims backed by the knowledge that every single commit
represents a working tree state that can be reproduced later by any user
of that branch.

What is worth the loss of that automated assurance, pushing the task
back to the user, making them manually manage such assurances in
advance?


I realise it's not your job to educate me about Darcs, especially in a
Bazaar forum, but it's all intended to be in aid of better understanding
the competition and whether perceived advantage of one over the other
represents something that should be addressed in one or the other. Thank
you for your persistence.

-- 
 \     “Are you pondering what I'm pondering?” “I think so, Brain, but |
  `\       wouldn't his movies be more suitable for children if he was |
_o__)              named Jean-Claude van Darn?” —_Pinky and The Brain_ |
Ben Finney