Peter Lundblad wrote:
> Mark Phippard writes:
>> On 3/7/07, Peter Lundblad <plundblad@google.com> wrote:
>>> Mark Phippard writes:
>>>> In the above scenario, when each pass of the merge runs it is possible
>>> that
>>>> one or more conflicts are created from the merge. If any conflicts are
>>>> created, then merge can finish the current pass it is performing, but it
>>>> cannot continue on to do the next pass unless those conflicts are
>>> resolved.
>>> I see No reason why the whole merge process needs to stop just because
>>> a subtree (possibly just a file) has conflicts. We just need to exclude
>>> that part of the tree and notify the user.
>>
>> I was involved in a long conversation on this topic with Dan, Paul Burba and
>> Jack Repenning while I was at CollabNet last week. Daniel made a very
>> convincing argument to me that it needs to be this way. Just think of the
>> simple case where you have two files foo and bar. Suppose that when we do a
>> large merge involving several "passes",there are conflicts in foo, but not
>> bar. So foo only has the initial revision range merged, and bar has all of
>> them. In some cases, this will be fine. But if foo relies heavily on bar,
>> it might become extremely difficult to resolve the conflicts in foo since it
>> is effectively at a much older revision than bar. foo could reference
>> functions in bar whose signatures have changed, or no longer exist. Even
>
> Say we are mergin revisions 1-8. foo already has revision 4, but not bar.
> The current merge alrogithm would do the following merges:
> 1) /foo, 1-3
> 2) /foo, 5-8
> 3) /, 1-8
>
> So what happens if 1) results in a conflict?
>
> We could stop immediately, leavning / *and therefore bar) without revisions
> 1-4. foor@2 might have introduced a dependency an bar@2 which
> makes it harder for conflict resolution.
>
> We could continue merging /, but only to revision 4. This would avoid
> dependencies *in this case*, but not in general, because if some other part of
> the subtree was merged before foo, then it might include newer revisions that
> might introduce dependencies. This could also cause lots of conflicts in
> the rest of the subtree (in a more interesting case than two files, obviously),
> that wouldn't have occured if / except /foo was merged all the way to
> revision 8.
>
> So, I think the assumption that we can leave the tree in a consistent
> state after a conflict is misguided. I also think we have to accept the fact
> that if you get conflicts in a complicated merge, you might not be able to
> compile/test the resolution before continuing the merge.
I would say it is more important to have a consistent wc state
for conflict resolution (including having all files on the
same revision, and being able to compile/test before continuing)
than supporting edge cases of merge tracking for individual files.
At the end, Subversion is revision based for a good reason,
not file based like CVS.
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 9 09:54:14 2007