Why Darcs users prefer Darcs over Bazaar

[Ben Finney]

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

> Ben Finney writes:
> 
>  > > 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]

Specifically “the state of the files”, which includes all tangible
properties of those files: contents, names, relative path location,
timestamp, filesystem permissions, ownership, etc. They're tangible in
that they are the objects we work with directly.

Not all these properties need to be tracked by the VCS (e.g. I don't
know any that track file ownership, since that would be counter to the
point of what most of them do). The important thing is that the tangible
unit to be tracked is those properties of files that, when altered, we
conceivably want to restore to the state of a previous revision.

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

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.

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

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

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.

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

What do you mean by “features”? My initial guess is that this means
“content in a file”, which leans back toward the concept of a patch as
“change in content that can be represented by ‘diff(1)’”, rather than
a richer set of state-change data in a “revision” in something like
Bazaar.

What do you mean by “application”? If you mean “program”, that
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. That's not true for anything but a limited set of programming
languages, let alone projects that are implementing things other than
programs.

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 :-)

All I'm seeing is that Darcs is a lossy VCS, that instead of tracking
useful information directly, depends on reconstructing it later via
inference that can sometimes be wrong.

Where am I going wrong?

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

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.

For those purposes, looms are better than Quilt or Mercurial Queues,
AFAICT. I don't understand Git or Darcs well enough to make a value
judgement there.

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

Exactly: purposes like that don't make sense for a series-constrained
loom, because the external constraint isn't there mandating a series.

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

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.

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.

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

-- 
 \        “I bought a dog the other day. I named him Stay. It's fun to |
  `\     call him. ‘Come here, Stay! Come here, Stay!’ He went insane. |
_o__)         Now he just ignores me and keeps typing.” —Steven Wright |
Ben Finney