Hi Paul,
thanks for your explanations!
On Tue, Jun 10, 2008 at 02:01:25PM -0400, Paul Burba wrote:
> On Tue, Jun 10, 2008 at 11:29 AM, Jens Seidel <jensseidel_at_users.sf.net> wrote:
> > On Thu, Jun 05, 2008 at 05:53:35PM +0200, Jens Seidel wrote:
> >> I noticed an unexpected behaviour during a merge with a recent 1.5
> >> snapshot. I tried to reproduce it but I (at least partly) failed.
> >>
> >> Nevertheless here is the story:
> >>
> >> * Create a branch as copy of trunk
> >> * Add a file to both, trunk and branch, (same filename and content, but
> >> no common history)
> >> * Rename the file in trunk
> >> * Remove the renamed file in trunk
> >>
> >> * Merge the renaming and removal in trunk to branch.
> >>
> >> The status in branch is now:
> >> M .
> >> D file
> >
> > Command was svn merge -r 2:4 URL
> > (r3: renaming, r4: removal)
> >
> >> If I merge first the renaming and after it the removal (without
> >> intermediate commit) I get:
> >>
> >> M .
> >> D file
> >> A + file.old
> >
> > That's equavalent to using svn merge -r 2:3 -r 3:4 URL
> > so "svn merge -r r1:r2 -r r2:r3" is not identical to "svn merge -r r1:r3"!
>
> 'svn merge -c8' == 'svn merge -c8,9' == 'svn merge -r7:8 -r 8:9'
> 'svn merge -c9'
>
> All three of the above *always* result in two merge editor drives. On
> the other hand, 'svn merge -r7:9', could result in two drives (if the
> source URL was renamed in r8) but could also (as in the example you
> give) result in only one editor drive. A lot of the time there will
> be no difference in the final result, but you've hit upon a case where
> there is:
Mhm, OK. So -r7:9 can be different from -r7:8 -r8:9 but if I specify
-r7:9 Subversion should never perform -r7:8 -r8:9, right?
That's not true in case of manual conflict resolution. This may cause
Subversion to split -r7:9 into -r7:8 -r8:9.
> The second merge is trying to delete a path scheduled for
> addition with history, merge won't do this unless you use --force.
> You didn't mention this, but I assume you saw that this path was
> reported as skipped during the second merge, something like this
> (using my own example to mimic yours):
Indeed, Subversion printed 'Skipped' without --force.
> If you reverted and tried the merge again with --force I expect you'll
> see what you expect:
Right!
> >svn merge %url99%/A A_COPY -c9,10 --force
> --- Merging r9 into 'A_COPY':
> A A_COPY\C\nu_renamed
> D A_COPY\C\nu
> --- Merging r10 into 'A_COPY':
> D A_COPY\C\nu_renamed
>
> >svn st
> M A_COPY
> D A_COPY\C\nu
>
> Notice the two '--- Merging' notifications? There we clearly see that
> two editor drives are occurring. Unfortunately the previous merge
Right! The same happens if a conflict occurs in the middle even if only
one revision range was provided.
> Don't really think it is a bug though.
OK, but it's also not obvious.
> Ugh, I could just scream. I think we might need to reopen issue #2829...
:-))
Jens
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-10 22:49:42 CEST