On IRC Bert has asked me on a couple occasions if merge tracking
should treat exiting conflicts as obstructions. In 1.6 and currently
in trunk, if an existing conflict is encountered during a merge we
raise another conflict. For example:
1) We perform a merge that results in a conflict:
1.7.0-dev@1143458>svn merge ^^/A A_COPY -c6
Conflict discovered in
'C:/SVN/src-trunk/Debug/subversion/tests/cmdline/svn-test-work/working_copies/merge_tests-119/A_COPY/D/H/omega'.
Select: (p) postpone, (df) diff-full, (e) edit,
(mc) mine-conflict, (tc) theirs-conflict,
(s) show all options: p
--- 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
2) Mergeinfo is recorded on the merge target describing the merge:
1.7.0-dev@1143458>svn pl -vR
Properties on 'A_COPY':
svn:mergeinfo
/A:6
3) And we have the expected conflict stuffs:
1.7.0-dev@1143458>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
C A_COPY\D\H\omega
Summary of conflicts:
Text conflicts: 1
4) A subsequent merge that effects the conflicted path raises a second
conflict on that path:
1.7.0-dev@1143458>svn merge ^^/A A_COPY -c7
Conflict discovered in 'C:/SVN/src-trunk/Debug/subversion/tests/
cmdline/svn-test-work/working_copies/merge_tests-119/A_COPY/D/H/omega'.
Select: (p) postpone, (df) diff-full, (e) edit,
(mc) mine-conflict, (tc) theirs-conflict,
(s) show all options: p
--- Merging r7 into 'A_COPY':
C A_COPY\D\H\omega
--- Recording mergeinfo for merge of r7 into 'A_COPY':
G A_COPY
Summary of conflicts:
Text conflicts: 1
1.7.0-dev@1143458>svn st
M A_COPY
? A_COPY\D\H\omega.merge-left.r5
? A_COPY\D\H\omega.merge-left.r6
? A_COPY\D\H\omega.2.working
? A_COPY\D\H\omega.merge-right.r6
? A_COPY\D\H\omega.working
C A_COPY\D\H\omega
? A_COPY\D\H\omega.merge-right.r7
Summary of conflicts:
Text conflicts: 1
5) Mergeinfo continues to accumulate on the target describing the latest merge:
1.7.0-dev@1143458>svn pl -vR
Properties on 'A_COPY':
svn:mergeinfo
/A:6-7
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):
>svn resolve --accept theirs-full -R .
Resolved conflicted state of 'A_COPY\D\H\omega'
>svn st
M A_COPY
MM A_COPY\D\H\omega
>svn merge ^^/A A_COPY -c7
--- Merging r7 into 'A_COPY\D\H\omega':
G A_COPY\D\H\omega
--- Recording mergeinfo for merge of r7 into 'A_COPY':
G A_COPY
--- Recording mergeinfo for merge of r7 into 'A_COPY\D\H\omega':
G A_COPY\D\H\omega
--- Eliding mergeinfo from 'A_COPY\D\H\omega':
U A_COPY\D\H\omega
>svn st
M A_COPY
M A_COPY\D\H\omega
>svn pl -vR
Properties on 'A_COPY':
svn:mergeinfo
/A:6-7
~~~~~
Are we satisfied with the existing behavior?
Bert - Did you have a particular use case in mind where the
alternative behavior is superior?
Paul
