On Dec 31, 2005, at 1:50 AM, Tommy Pettersson wrote:
Your work in ~/working/product is parallel to the update in
[*1], and thus causes some conflicts resulting in "first
level" mergers which you cover with resolving patches in
[*2]. This is normal and quite harmless.
So we start with some base, B. Then there are two patch sets, W0 and
B0 that are work in parallel. So (in an informal syntax), this means:
~/base: B + B0
~/working: B + W0
Then I do the pull from ~/base, merging the parallel patches of B0 + W0:
~/base: B + B0
~/working: B + (B0 || W0)
Then I resolve some conflicts, with patch W1:
~/base: B + B0
~/working: B + (B0 || W0) + W1
Your second update in [*3] is _also_ parallel to all your
work in ~/working/product _and_ to (parts of) the first level
mergers and your resolve patches. This causes conflicts
with previous conflicts and produces "second level" mergers,
which are exponential in time with current darcs.
So, that is to say, the new work in base (actually grabbed from CVS),
B1 is this:
~/base: B + B0 + B1
~/working: B + (B0 || W0) + W1
Your point is that pulling B1 into working makes darcs do the really
hard work of
~/working: B + ( ((B0 || W0) + W1) || (B0 + B1) )
And that is just not going to be anything but exponential. (I sort
of understand from the Patch Theory page that darcs is going to have
to unravel (B0 || W0) and then fiddle all about trying many
combinations of patches.)
In this case you should pull all patches from ~/working/product
to ~/base/product before the second update in [*3] (or at
least the patches that conflicted with the first update
and their resolutions). Then the record in [*3] will be
"on top of" the conflicts and resolutions and therefore not
be parallel and conflict with them when you pull the second
update to ~/working/product.
It seems you are suggesting that I should have pulled into base from
working:
~/base: B + (B0 || W0) + W1
~/working: B + (B0 || W0) + W1
And then update from CVS and let it mark the conflicts and fix the
conflicts there by hand, producing B1', which looks like the work for
B1 had been done after my merge:
~/base: B + (B0 || W0) + W1 + B1'
~/working: B + (B0 || W0) + W1
This is sort of sad - since it is basically saying that CVS is better
at handling this sort of conflict (or at least it is better at giving
up and simply asking me to handle it) than darcs.
For example, what if ~/base was my local copy of a central darcs
repo? I wouldn't have the chance to modify B1 to make it look like
it happened after (B0 || W0) + W1. I would have no option but to
pull it. Which, as we know, won't really ever complete.
Surely in large darcs projects, this sort of scenario comes up all
the time. One can't always commit one's work to the common main line
before one has to grab the newest patches from main line. And
sometimes, like in this case, two such grabs need to happen before
you can push. What do folks do in this kind of case?
- Mark
Mark Lentczner
http://www.ozonehouse.com/mark/
[EMAIL PROTECTED]
_______________________________________________
darcs-users mailing list
[email protected]
http://www.abridgegame.org/mailman/listinfo/darcs-users
