Petr Rockai <[email protected]> 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 True. >> 4. Pushing and pulling between branches would be very hard to >> implement [snip] > 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 handling. >> 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 itself. 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. G. _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
