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

[Max Battcher]

Petr Rockai wrote:
> 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.

Note: "these four commands". I'm pretty sure my caveat there was solely 
for ``darcs-branch switch`` and working branch application with 
theoretical "lazy multi-branch repos". You could do "trivial" working 
branch application without darcs given a full pristine copy for the 
branch you are switching to. I was assuming that a lazy repository would 
not grab the other root keys' pristine objects other than "main" and 
then extrapolating from that a "trivial" working branch application 
_might_ need darcs to fetch the lazy pristine objects of other branches.

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

There is no need for a "new kind of context". ``darcs changes 
--context`` is just fine. You suggest that darcs does magic when the tag 
at the bottom of a context is missing, but it is fairly simple process:

1) darcs sees a tag it doesn't recognize at the bottom of the context
2) darcs requests that tag from its available sources, which includes 
both the current "remote repo" (in such cases), but also anything listed 
in _darcs/prefs/sources such as global cache sources

There is nothing that a ``darcs-branch`` would need to add to make 
contexts work in this situation, it should work exactly as it always 
does. At worst, the tool would need to make sure it populates a useful 
cache source somewhere. More likely than that is darcs will already find 
the patch it is requesting waiting for it in _darcs/patches and that's that.

Also, as I mentioned above: a "trivial" and/or "stupid" sort of working 
branch applications can be done with just the pristine copy and no need 
for applying/unapplying patches. Where you might want darcs patch magic 
is in preserving working copy changes (ie, unrevert and pending support) 
and conflict resolution, and presumably there might be nice things that 
you can do at the darcslib level.

However, I would imagine starting with the "trivial" version (which ends 
up looking not too far removed from other SCSes "typical" revision 
swapping) and add in darcs fu at a later point, if it is 
requested/necessary. Given "trivial" switching I don't see a need for 
any patch application/unapplication to be done by a ``darcs-branch`` tool.

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

Plus, if the out-of-darcs implementation goes sour darcs isn't left with 
vestigial commands or modules...

--
--Max Battcher--
http://worldmaker.net