Peter Lundblad wrote:
> Daniel Rall writes:
>> On Fri, 09 Feb 2007, Peter Lundblad wrote:
>>
>>> Daniel Berlin writes:
>>>> On 1/29/07, Peter Lundblad <plundblad@google.com> wrote:
>>>>> Not exactly, since the conflict might actually be blocking further merging.
>>>>> And if/when we get atomic moves, it might be necessary to do merging
>>>>> in revision order to get things right.
>>>> Yeah, but it would already be in the right order.
>>>> That's why it's not stored in some unordered form.
>>>> You know what revisions you will have to apply after the conflict is
>>>> resolved, since they are in the queue.
>> ...
>>> What I mean is that if you merge file a and because of chery-picking, the merge
>>> gets split into a few pieces, then in the first merge, you get a conflict
>>> and wait for the user. The user makes her choice. Then you have to do
>>> the rest of the merges which might take some time and the user has to wait.
>> ...
>>>>>> This is actually the approach i greatly prefer. If you go to get your
>>>>>> coffee, the merge will be as far along as it can make it without human
>>>>>> intervention, and will nicely be ready for you to help it fix the
>>>>>> rest.
>> In merge-tracking land, because we have to stop merging after the
>> first unresolved conflict is encountered, the "go and get your coffee"
>> approach simply doesn't work.
>
> We have to stop merging the particular file, but we can still continue
> merging the rest of the tree, ignoring the conflicted files and
> keeping track of that in the merge tracking info.
Does you mean the following:
File A may have conflicted by merging in r1000,
and r2000 is never merged in.
File B successfully has merged in r1000 and r2000.
Is this correct?
But usually, r2000 of A and r2000 of B need each other.
This means, if you manually have resolved the conflict in file A,
then you cannot compile and test your work,
because B includes r2000, but A does not include r2000 yet.
Is this right?
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 12 12:12:32 2007