Grant Husbands
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.