On 7/18/06, Reedick, Andrew <Andrew.Reedick@bellsouth.com> wrote:
> > -----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
> info*
> > A svn-test-work/working_copies/merge_tests-31/A/D/G/rho *dir merge
> info*
>
> 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.
Ahh, but the problem is that you're talking about a different set of
problems. This test doesn't actually have any merge into the file in
question, it's just merging the add of the file into a location where
another file was deleted. It's a separate problem from the one you
originally found, it just happens to have a latent bug that is tripped
by the fix for your problem.
-garrett
---------------------------------------------------------------------
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:31:36 2006