[darcs-users] cheap in-repo local branches (just needs implementation)

Grant Husbands darcsusers at grant.x43.net
Wed Jul 22 15:48:39 UTC 2009

Petr Rockai <me at mornfall.net> wrote:
>> 1. When you unpull old patches or reorder patches, Darcs alters
>> existing patch files. This will break other branches that share the
>> same files.
> Not true, since the filenames are fully determined by the file content. Hashed
> repositories will just create a new file for the modified patch.
[2. Same]

Ah, my mistake, sorry; I see that in Darcs 2 the patch filename format
changed. In Darcs 1, it was not dependent on the content. Sorry about
that; I should have double-checked before making the claim.

[3. Unpulling can break other branches]
> This can be addressed by a GC policy


>> 4. Pushing and pulling between branches would be very hard to
>> implement
> The proposed thing is the exact mechanism behind "darcs push"

Generated contexts are like the inventory; they only list patches up
to the last tag (pretty much); If that tag isn't present in the
receiving repository, then more effort is entailed in finding a common
point before the operation can proceed. Darcs internally handles that
when it can see both repos at once. In the proposed solution, that
doesn't hold.

(Note that I've not looked at the Darcs internals for a long while,
but Darcs must internally handle those things somehow)

> The "switch" problem wouldn't be any easier whether implemented inside or
> outside of darcs.

It seems to me that, inside of Darcs, it's easier to keep track of
contexts for all these patches, as it already has all the
patch-and-context-handling machinery and can handle the intermediate
states internally. Outside of Darcs we either have to implement a lot
of the same logic or work out some non-trivial patch export/import

>> 6. As noted in the proposal, it's not known how to make it play nicely
>> with lazy fetching.
> I don't expect any problems here. I also don't see the original note?

The original note that I should have quoted was from Max Battcher:
: Additionally, there would be other useful management tools
: (``darcs-branch list``, ``darcs-branch remove`` (or unfreeze)). I think
: that these four commands could be done with no darcs interaction at all
: (unless the branch being switched to has an incomplete/lazy pristine).

Overall, I'd say this just feeds back into my original point, though;
I fully expected that many points could be answered, and I think I can
raise more, given a bit of thought. (I won't unless I'm asked to,
though, as I'm trying to raise a useful point, not trying to wield
pedantry to kill a project.)

However, take even just the above into account and things are now more
complicated. We're no longer simply switching a pristine and an
inventory here and there, we're applying and unapplying patches for
the working copy (which is non-trivial if you want to get the contexts
correct), and rolling back on failure (something even Darcs has
historically had trouble with). We're extending the added GC roots to
include the full inventory chain (and whatever else comes up). We're
doing something interesting with a new kind of context to make patch
migration between branches work. I think it will become at least as
much work as it would take to implement the right mechanisms in Darcs

There's also the strong possibility that the system would get mostly
implemented, with a few gotchas here and there and a few incomplete
features, and then there'd less impetus for writing a good, integral
branching system.

I'd be happy to be proven wrong, though.


More information about the darcs-users mailing list