Petr Rockai wrote:
Grant Husbands <[email protected]> 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
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
