On Wed, Jul 6, 2011 at 12:35 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Wed, Jul 06, 2011 at 12:23:25PM -0400, Paul Burba wrote:
>> One alternative would be to stop nesting conflicts if merge tracking
>> is active and treat existing conflicts as obstructions. Using the
>> existing merge tracking infrastructure for marking skipped subtrees as
>> untouched by a merge, we could leave the initial conflict and add
>> subtree mergeinfo on the conflicted path to reflect that the
>> subsequent merges didn't touch it. For example, in step 4 we could do
>> this instead:
>>
>> 4) Instead of creating a second conflict we skip the existing conflict:
>>
>> >svn merge ^^/A A_COPY -c7
>> Skipped 'A_COPY\D\H\omega'
>> --- Recording mergeinfo for merge of r7 into 'A_COPY':
>> U A_COPY\D\H\omega
>> G A_COPY
>> Summary of conflicts:
>> Skipped paths: 1
>>
>> >svn st
>> M A_COPY
>> ? A_COPY\D\H\omega.merge-left.r5
>> ? A_COPY\D\H\omega.merge-right.r6
>> ? A_COPY\D\H\omega.working
>> CM A_COPY\D\H\omega
>> Summary of conflicts:
>> Text conflicts: 1
>>
>> 5) Mergeinfo is updated on the merge target as expected, but is also
>> added to the conflicted path, but *only* for the first merge (r6):
>>
>> >svn pl -vR
>> Properties on 'A_COPY':
>> svn:mergeinfo
>> /A:6-7
>> Properties on 'A_COPY\D\H\omega':
>> svn:mergeinfo
>> /A/D/H/omega:6
>>
>> With the change in behavior it is arguably(?) easier to resolve the
>> first conflict then repeat the merge (where merge tracking sees that
>> the omega hasn't had r7 merged and applies only that part of the
>> diff):
>
> What if users run 'svn revert' as part of resolving the conflict?
> Revert would remove the explicit mergeinfo, so subsequent merges
> won't try to merge changes for r7 again.
> So I think we'll need some other approach.
You mean if the user reverts only the conflicted subtree right? If
so, I see your point, but I'm not sure we can make any assumptions
about what the user expects in this particular case. They may very
well revert the conflict because the reverted result is what they
want; they may not want r7 to be merged again! Or as you imply, they
may revert the conflict because they want to deal with that subtree
problem later. The fact that both of these expectations seem valid is
a strong argument for keeping the existing behavior (and yes, I'm
beginning to wonder if there is any issue here at all :-)
> We could have 'svn merge' check for conflicts in the working copy
> upfront and refuse to run the merge unless a special option
> (--allow-conflicts?) was passed. Like we already do for mixed-revisions.
That would be somewhat analogous to how we handle multiple editor
drives when a drive results in a conflict before all the drives are
complete, i.e. we stop and suggest resolving the conflicts before
continuing:
>svn merge ^^/A A_COPY -c6 -c7 --accept postpone
--- Merging r6 into 'A_COPY':
C A_COPY\D\H\omega
--- Recording mergeinfo for merge of r6 into 'A_COPY':
U A_COPY
Summary of conflicts:
Text conflicts: 1
svn: E155015: One or more conflicts were produced while merging r5:6 into
'C:\SVN\src-trunk\Debug\subversion\tests\cmdline\svn-test-work\working_copies
\merge_tests-119\A_COPY' -- resolve all conflicts and rerun the merge to apply
the remaining unmerged revisions
I don't think such an option is necessary though. In the N-editor
drive case the user can't reasonably know that some drive <N is going
to create a conflict, so the existing behavior stops the madness and
gives them a chance to resolve "reasonable" conflicts. And where the
problems of merging into a mixed-rev working copy are subtle and easy
to unknowingly stumble into, merging into a working copy with
pre-existing conflicts isn't something you accidentally do (unless you
frequently merge without even checking the basic status of the WC).
Requiring a new option to do this may be too far down the road of
protecting users from themselves.
Paul
Received on 2011-07-07 16:19:27 CEST