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

[Eric Kow]

Hi Miles,

[Hi Petr, if you have the time, Miles' question #5 might be interesting
 for you to answer because I think you know the most about Git internals?]

On Thu, Nov 11, 2010 at 15:15:13 +0000, Miles Gould wrote:
> I stupidly volunteered to give a talk about DVCS to my local Perl
> Mongers group tonight, and I have a few questions about darcs (which
> I've used in the past, but not for anything very advanced). Eric Kow
> suggested I ask them here - I hope that's OK.

I realise your talk has long passed, but in case this is useful for
the future or for other darcs-users readers.

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

My (limited) understanding is that darcs 2 conflictors contain
information (contexts of conflicting patches? - not sure), which avoids
the need for the kind of nesting that leads to the exponential merge
problem.  It's not that the nesting goes away -- it can still happen and
darcs can still blow up -- but in a lot of common cases, Darcs will
behave a lot better.

Come to think of it, I'm probably the least qualified in the Darcs
team to talk about core-level Darcs.  If you hear from Ganesh,
Florent or Petr and they contradict anything I say, they're probably
more likely to be right.  Maybe even Ian will chime in if he has some
time.

> 2) What exactly is a "preparation branch"? I'm guessing that you have
> two checkouts - "messy" and "preparation", say - do your actual work in
> "messy" and then pull selectively from "messy" into "preparation" so you
> get a nice flow of history before you push upstream (rather like a git
> rebase --interactive, but more heavyweight). Or have I totally
> misunderstood?

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.

I think the original author of this page, Mark Stosberg (?) was
intending a sort of compare and contrast approach in talking about
workflows, ie. that

- darcs and git *both* support preparation branches
- darcs also supports spontaneous branches

> 3) Do people really use spontaneous branches? This kind of "magic
> string" stuff makes me really nervous, and is the kind of thing that
> gave Perl programmers such a bad name!
> [I'd also object that they're neither spontaneous nor branches, but
> language is often funny like that.]

I don't think I make much conscious use of it.  Well, if I have a
project with some sub-projects, I do sometimes record patches patches
that start with the sub-project name, thinking that this will make it
easier for me to find them.

Personally, I'd be happier if we re-thought that page completely and
de-emphasised the magic string stuff because (A) I suspect it does not
reflect reality [in the sense of what people actually do] and (B) it
distracts from what may be a more important point about "spontaneous"
branching, which is that you don't have to anticipate the need to
branch.

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?

See what I'm getting at?

I still like the "spontaneous" part of the spontaneous branching page.

I can see that the special patch naming conventions talk can help people
to grasp the possibility of spontaneous branching in Darcs, but on the
other hand, it also seems to misdirect people by making them think it's
about these conventions. Surely we can do better!

> 4) Are there plans to give darcs branch-in-place functionality like
> Git's? I see that there was discussion of this last year
> (http://lists.osuosl.org/pipermail/darcs-users/2009-July/020565.html) -
> did anything come of it?

Ideas being kicked around:
- http://wiki.darcs.net/Ideas/Branches
- http://wiki.darcs.net/Ideas/NewRepositorySemantics

Two points:

1. I think that as I continue participating in the Darcs project, 
   I am slowly-slowly becoming a little bit more "focused"...
   which means that whereas Eric from two years ago would have
   been more eager about this, Eric-2010 is more likely to see it
   as a distraction. [I realise it's important to a lot of people,
   and I'm not saying that we won't work on this, especially since
   it's only my opinion here and not the rest of the team.  I just
   feel that (A) this is a usability issue and (B) there are bigger
   usability fish to fry, eg. conflicts]

2. ...that said, we may end up needing to think about local branching
   after all to make things like darcs rebase work nicely (do I remember
   that correctly?)

So maybe #2 will cancel out #1.

So there are no formal plans as such. I can say for myself that I've
grown a bit cooler to the idea, but others on the team may be a lot more
enthusiastic.

> 5) Slightly bigger question: how much does darcs' hashed-storage format
> borrow from/share with git's repo format?

This would be a fantastic time for Conspicuous Use of Archives...
[sorry it's one of the drums I like to bang on] except I can't think of
any resources to link to, like past discussions.  Googling "darcs hashed
git" didn't seem to turn up any leads.

There is this wiki page that Petr wrote:
  http://wiki.darcs.net/Internals/HashedPristine
Maybe after this thread, it needs to grow a section about relationship
with Git?

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

Darcs implemented these ideas after 1.0.9 (they could have been released
as a darcs 1.1.0 without the darcs 2 patch semantics, which maybe would
have been helpful).  Hashed-storage is a library that Petr developed in
his Summer of Code project which is a sort of
reimplementation/generalisation of the ideas in the darcs hashed format

Perhaps Petr, who knows hashed-storage inside and out and also knows
quite a bit about Git can answer your question properly and correct
any silly things I say.

> 6) This is pretty clear from the release announcement, but I'd like to
> sanity-check: is it now the case that the time taken to check out a repo
> is now independent of the number of patches in that repo? Or is that
> just with --lazy? What does it depend on? I'm guessing it's at least
> O(n) in the number of bytes in the checkout.

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

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
For a faster response, try +44 (0)1273 64 2905 or
xmpp:kowey at jabber.fr (Jabber or Google Talk only)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20101122/fa96bce8/attachment-0001.pgp>