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

RE: Conflict when merge tries to add

From: Reedick, Andrew <Andrew.Reedick_at_BellSouth.com>
Date: 2006-07-19 01:00:16 CEST

> -----Original Message-----
> From: rooneg@gmail.com [mailto:rooneg@gmail.com] On Behalf Of
> 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:
> D svn-test-work/working_copies/merge_tests-31/A/D/G/rho
> A svn-test-work/working_copies/merge_tests-31/A/D/G/rho
> But with my patch you then get the following in dry run mode:
> D svn-test-work/working_copies/merge_tests-31/A/D/G/rho
> C svn-test-work/working_copies/merge_tests-31/A/D/G/rho
> 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.

Ok, I have a ClearCase background, with lots of Evil Twin and directory
merging experience. IMHO, here's what I see:

        There are *2* merges being done. The first is the directory
merge where you decide which branch's rho object to use. The second
merge is the file contents merge of the two rho objects. The question
is, which of the two merges do you want to report on? (Or report both?)

        It looks like merge and --dry-run report on the directory merges
(the first merge.) The patch would tell 'svn merge' to report on the
second merge, the file content merge.

> D svn-test-work/working_copies/merge_tests-31/A/D/G/rho *dir merge
> A svn-test-work/working_copies/merge_tests-31/A/D/G/rho *dir merge

        This is correct for the 1st pass, directory merge.

> D svn-test-work/working_copies/merge_tests-31/A/D/G/rho *unwanted
dir merge info*
> C svn-test-work/working_copies/merge_tests-31/A/D/G/rho *good-
file merge info*

        The 'C' is correct for the 2nd pass, file content merge, if the
contents of the two rho's really are different. However, the 'D' is a
leftover from the directory merge and, IMO, should *not* be printed. I
don't really care where the rho objects came from[1], I care more about
file contents of the rho objects.

        Again, the real question is whether to stop reporting that two
objects were merged (the 1st pass dir merge) and just report on the 2nd
pass file content merges?

        If I'm way off base with my assumptions and ClearCase bias, let
me know, and I'll butt out. =)

        On a side note, --dry-run underreports so I never use it,
because it's output is "incorrect." It doesn't seem to walk into merged
directories (which is understandable. ClearCase does the same thing,
but spits out a 'dir merge needed' warning. In ClearCase, you would
iteratively do all the dir merges until there were no more, and then do
one merge against the file contents.) So if you break --dry-run to fix
the merge output, I'm ok with that. ;-)

[1] However since ancestry determines history and affects merging,
there are times where I do care about which rho object was merged into
the dir. Especially if I'm storing bug numbers in the commit messages.


The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 19 01:01:00 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.