[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

merge 105, issue 3115: case-only rename merges

From: Greg Stein <gstein_at_gmail.com>
Date: Fri, 27 Apr 2012 22:35:17 -0400

Hey Paul,

I think that I just found a bug in case-only renames, via merge_tests 105.

When the merge -r2:3 is done into the working copy, there are two
possible outcomes:

2012-04-27 22:21:59 [INFO] --- Merging r3 into
2012-04-27 22:21:59 [INFO] A
2012-04-27 22:21:59 [INFO] D
2012-04-27 22:21:59 [INFO] --- Recording mergeinfo for merge of r3
into 'svn-test-work/working_copies/merge_tests-105/A_COPY':
2012-04-27 22:21:59 [INFO] U

2012-04-27 22:23:27 [INFO] Skipped
2012-04-27 22:23:27 [INFO] --- Merging r3 into
2012-04-27 22:23:27 [INFO] D
2012-04-27 22:23:27 [INFO] --- Recording mergeinfo for merge of r3
into 'svn-test-work/working_copies/merge_tests-105/A_COPY':
2012-04-27 22:23:27 [INFO] U
2012-04-27 22:23:27 [INFO] Summary of conflicts:
2012-04-27 22:23:27 [INFO] Skipped paths: 1

The difference is the order of the editor drive. The "good" form sees
"D mu" first. The "bad form" sees "A MU" first.

I suspect in the bad form, it sees a case-only conflict and decides to
skip the path. Badness ensues.

I've verified this behavior by manually flipping the order of these
two changes during the editor drive.

I don't think there is anything that says we will see deletes first,
followed by adds. It just "happens" to have done that so far. But my
recent work ended up changing that order. Boom.

Any thoughts on what is going on here? Is there some kind of
case-conflict check that causes that skip to happen? (or is it
something else?) ... and the bigger question: how can you get this to
work when the changes arrive as MU-first, mu-second?

Received on 2012-04-28 04:35:50 CEST

This is an archived mail posted to the Subversion Dev mailing list.