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

[Mark Williamson]

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

Do you have a link to that, at all?

Cheers,
Mark

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