[darcs-users] Questions about darcs (esp. branching)

[Miles Gould]

Thanks very much for the response, Eric.

On Mon, Nov 22, 2010 at 10:37:10AM +0000, Eric Kow wrote:
> I realise your talk has long passed, but in case this is useful for
> the future or for other darcs-users readers.

I may give similar talks in future :-) In particular, if I can get my
head around the connection to inverse semigroups (or better, to Cockett
& Lack's notion of restriction categories) then I could perhaps give a
mathier talk about darcs to my university's theory group.

> > 1) Am I right in thinking that the "exponential merge" problem is now
> > (a) much rarer, (b) exponential in the number of conflicts rather than
> > the number of {patches nested on top of a conflicting patch}? That seems
> > to be what http://wiki.darcs.net/ConflictsFAQDarcs1 says, but I could be
> > misinterpreting.
> 
> That said, I think (a) sounds right, but I don't understand (b).

Suppose you pull in patches N1, N2, ... N10, with N(n+1) depending on
Nn, and odd-numbered patches conflicting directly with something already
in your repository. Then (in the terminology I was using) your nesting
depth is 10, but there are 5 conflicts.

Or have I misunderstood the definition of "conflict"? Is there no real
distinction here?

> Reading the http://wiki.darcs.net/PreparationBranches article you're
> likely referring to, it seems like "preparation branch" is just a fancy
> way of talking about the workflow that results from using any DVCS, ie.
> being able to prepare your patches/commits locally, editing them at will
> and only sending them when you're good and ready.

Oh, I see. 

> You don't have to say "oh, this looks like a separate/orthogonal
> feature; so I'll cut a branch now" (although you can if you want to).
> Rather you can just hack-hack-hack, and then later on decide that
> actually you've been working on two different things and maybe
> retroactively branch+cherry pick if you want.  I tend to suspect that
> Darcs workflows need less branching, that it's easier to work in a
> single branch (due to the set-of-patches approach and exact patch
> application), but maybe I just don't use Git enough to have a proper
> appreciation of branching?

It's perhaps not obvious from my slides, but this was the real point of
my talk: what git does with topic branches (ad-hoc branches that you
create for each new feature and dispose of after a few hours or
minutes), darcs does with cherry-picking (and vice versa). This is
practical on the darcs side because darcs automatically tracks patch
dependencies, and it's practical on the git side because git makes
branching ridiculously easy. 

Hence, a darcs user looks at git and says "Git doesn't support
dependency-aware cherry-picking, how useless; why should I care about
easy branching?", and a git user looks at darcs and says "Darcs doesn't
support easy branching, how useless; why should I care about
cherry-picking?". But to say that "git doesn't support real
cherry-picking" or "darcs doesn't support lightweight branching" is to
miss the point: the correct unit of merging in git is the topic branch,
but the correct unit of merging in darcs is the patch (+ dependencies).

I think of it as optimistic versus pessimistic dependency-tracking: git
pessimistically assumes that a commit depends on all patches that
precede it in the history graph (and requires the user to branch to
indicate independence), darcs optimistically assumes that patches only
depend on previous patches that touch the same code (and presumably has
some way for the user to specify additional dependencies?).

[BTW: the "retroactively branch + cherry-pick" thing works fine in git
too, but you'll have to cherry-pick all the necessary patches into your
new branch manually. Because `git cherry-pick` does something
fundamentally different to a darcs cherry-pick :-)]

> Note: I think you're asking about the darcs hashed format which uses the
> idea of
> 
>  - files identified by a hash of their contents (patches, pristine, inventory)
>    [also in darcs, the way the files are stored is by using the hash as
>    a filename for these files]
>  - manifests pointing to other manifests or files

All of those ideas sound extremely similar to git's unpacked repo
format.

> In hashed format repositories we have to fetch at least a copy of
> pristine so darcs get --lazy time will depend on the size of your
> tree.  Doing a full get will depend on the number of patches.
> 
> Darcs 2.8 will hopefully include a darcs optimize --packs optimisation
> (which I don't think is quite the same as Git packs) which basically
> builds two tarballs, one of the pristine cache (for darcs get --lazy)
> and one of the patches so far (for full get).

That's very clear - thanks!

Miles

-- 
The minute you believe numbers uncritically, that is, without
understanding how they're calculated and how well they measure whatever
they're supposed to measure, you will generate a breed of employee who
will produce numbers and not results.  Your data-processing system will
then serve not to describe reality but to lie about it.
  -- Michael S. Montalbano