> Folker Schamel writes:
>> Peter Lundblad wrote:
>> 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?
>>
> Yes.
>
>
>> 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?
>>
>
> You can't sometimes, so you need to restart the merge where it left
> (note that this is all done in a local WC without commits in
> between). But the question of interactive or not doesn't change that,
> does it?
They are separate issues, but they are related to each other:
I just think it is very important that for resolving merge conflicts
the user is not restricted. Often the user needs all his development
tools (editor, compiler, automated test, manual tests etc.) to fix a conflict.
In the same way as today the user often needs to use all his development
tools for fixing classical update conflicts.
To make this possible, this requires a working copy having
no mixed revisions. And, as second aspect, GUI callbacks
are too restrictive for using all your development tools.
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 16:01:13 2007