[Haskell-cafe] Re: cheap in-repo local branches (just needs implementation)

[Petr Rockai]

Grant Husbands <darcsusers at grant.x43.net> writes:
> 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).
Ah, OK. This is mistake on Max's part, since there's no such thing as
incomplete/lazy pristine. I.e. this is a non-issue.

> 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.)
Well, the problem with that point is that maybe half of your points were
trivially untrue, which sort of puts a dent into the argument itself. :)

> 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
> itself.
No-one says it is going to be less or more work to do this within or outside of
darcs. No doubt, some darcslib usage is quite likely (for patch application and
unapplication, eg.). However, it is still relatively manageable, and in a
limited form also relatively easy (but that's true of almost anything, the
80/20 rule).

> 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.
You are probably overdoing the "integral" part of the equation, given that the
only difference is administrative. You can import parts of darcs from outside
of darcs just fine, these days. Anyway, the 80/20 problem is equivalently
applicable to in-darcs as it is to out-of-darcs implementation.

Yours,
   Petr.