[darcs-users] some darcs comments from Johan Tibell

Stephen J. Turnbull stephen at xemacs.org
Sat Jan 2 16:47:31 UTC 2010

Johan Tibell writes:
 > > I just had a thought on one principle we could adopt that could help
 > > us preserve this simplicity.  Johan: since you're an active user of
 > > branches, could you comment on the following idea?
 > >
 > >  Darcs should never implement 'remote' branches.

I'm not Johan, but let me comment anyway.

I don't understand who you are trying to save from what here.

At the lowest level, you're saying it matters whether the patch I need
is currently stored locally or in some other repository.  That's
clearly a mostly bogus distinction.[1]  Copy the patch and be done
with it, OK?

The next level problem is that if your VCS supports colocated
branches, you might commit to the "wrong" branch because you forgot
which one you're in.  Fixing this is just a rebase (and maybe
splitting the first patch).  Well, hey, isn't Darcs the world's best
tool for rebasing, and no slouch at splitting up patches?  And note
that this can surely happen without *remote* branches.

Finally, when pushing or pulling you could indeed make a big mess by
increasing the number of branches and silently switching to the
"wrong" one.  That's a real problem for Darcs, I think, just as for
git, but git's solution (and Mercurial's, and Bazaar's) should be
applicable here: by default, remote operations are only permitted if
they are fast forwards.  (I'm not sure exactly what "fast forward"
means in the context of Darcs, but to the extent that it's somewhat
fuzzy that's precisely because Darcs knows how to handle most
situations, I think.)  In other words, Darcs is only allowed to
increase the number of branches in the target repo if the user
specifies the branch to add *and* some kind of "new branch" option.

I can think of one use case where pulling a remote branch would be
very useful.  That is the case where bootstrapping your project is
very expensive.  The workflow here is to create a repository in one of
the usual ways, and bootstrap it.  Now, if you want to test someone's
changes, instead of cloning their branch (moderately to very expensive
in a big tree) and bootstrapping (very expensive), you simply pull the
delta to their branch into your "build&test" working tree and remake
the changed files.

 > > Branches should be strictly a personal affair, something a hacker would
 > > use to work on multiple features at the same time, or a maintainer to
 > > keep track of a bunch different patch sets; but NOT for a project that
 > > wants to publish multiple branches (they'd have to do it the old
 > > fashioned way).

I use git to synchronize multibranch repositories across several hosts
all the time, and I just don't see a problem, as long as I don't
rebase.  In fact, in a couple of cases I've had several wildly
divergent versions, and I just pull the branches into one repo from
wherever they might be, and mix and match with cherry-picks and merges
until I've achieved a set of sane up-to-date branches.  I see no
reason at all why Darcs shouldn't be even more efficient for this kind
of thing.

 > >> Aside: I want all my history locally so I don't use lazy.
 > >
 > > Even when branching an already local repo?  What's there to lose?
 > I didn't really use local branches in Darcs but I imagine that --lazy
 > would be fine that although perhaps subsumed by hard linking. I find
 > that to be an optimization that the tool (i.e. Darcs) should worry
 > about.

Very true!  But coming up with a robust and simple policy is not easy.
Eg, git's defaults are now quite efficient, but the record of false
starts is easily visible in the list of space-optimizing options to
"git clone".

[1]  I say mostly bogus because Emacs is experiencing a lot of pain in
their transition to bzr, and a certain portion of that pain is due
simply to the fact that that the Savannah admins took advantage of the
flexibility in transports of remote versions that bzr offers to
pessimize checkout and clones of branches.

More information about the darcs-users mailing list