On 7/13/06, Garrett Rooney <firstname.lastname@example.org> wrote:
> As was recently pointed out by Andrew Reedick on the users list,
> currently, if 'svn merge' tries to add a file and that results in a
> conflict (say there was a different file with the same name added on
> both a branch and the trunk, and then you try and merge the branch
> into the trunk) we print out an A, not a C. There's a trivial change
> to fix that, but it causes some test failures, so I figured I should
> bring it up here to make sure that we really should print C. I mean
> it makes sense to me, but clearly someone at some point decided that
> printing A was correct, otherwise they wouldn't have wrote the tests
> that confirmed it...
> Just an oversight?
> Here's the diff to fix the problem (minus fixes to merge tests, those
> are trivial enough though):
> When a merge of an added file results in a conflict display a C,
> not an A.
> * subversion/svn/notify.c
> (notify): Check for conflicts when a merge results in an add, and
> alter output accordingly.
Ok, so it turns out it's not as trivial as I'd hoped to fix the
tests... This bug is actually masking another bug, specifically one
in dry run merges.
There are a few merge tests that involve merging replacements of
files, meaning they delete a file, then merge a change into the
working copy that results in it being added. Currently, that results
in output like:
But with my patch you then get the following in dry run mode:
That's clearly not right, as it's not conflicted at all! Why does
--dry-run mode think it is? Well, because the D line didn't actually
delete the file, it just said it did. That means that later on when
we hit the add operation it decides it was a conflict because the file
is still there. This used to print an A because we ignored the
conflict status in the notification callback, but with my change it
now prints a C.
So in order to fix this problem without introducing more problems we
have to make dry run merges record the operations they're doing (with
regard to removing and adding files, at least), so they can become
smart enough to reference that data rather than actually going to the
filesystem when asking this kind of question.
I suppose I'll probably open an issue about this, because it's clearly
more work than I'd initially though, and I'm not sure when I'll get a
chance to delve more deeply into this.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Jul 19 00:13:39 2006