Hi,
is no one willing to comment this or is it already known?
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.
>
> Since the files in trunk and branch share no common history I'm unsure
> whether the merge should conflict. It didn't, OK (I first expected this).
>
> 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"!
> Is this a bug? At least after reading the changelog and especially
> 'svn copy A B ; svn move B C' now the same as 'svn copy A C' (issue #756)
> I assume that there should be no other result. It should not matter
> whether I split the merge into two merges or not. Right?
>
> I tried to reproduce a situation in my large repository where a merge of
> both actions at a time resulted exactly (no svn:mergeinfo change) in:
> D file
> A + file.old
>
> But please note that I had a conflict in this directory (before the
> rename) which I resolved interactive and now I wonder whether this
> interactive merge is aquivalent to separate merges. I assume that
> without the conflict I would just get:
> D file
>
> PS: issue #756 was reopened. Should it stay fixed in the CHANGES file?
Please have also a look at the svn merge help:
3. merge [-c M[,N...] | -r N:M ...] SOURCE[@REV] [WCPATH]
I wonder about specifying "N" for option -c. The help text doesn't
explain it:
3. In the third form, SOURCE can be either a URL or a working copy
path (in which case its corresponding URL is used). SOURCE (in
revision REV) is compared as it existed between revisions N and M
for each revision range provided. If REV is not specified, HEAD
is assumed. '-c M' is equivalent to '-r <M-1>:M', and '-c -M'
does the reverse: '-r M:<M-1>'. If no revision ranges are
specified, the default range of 0:REV is used. Multiple '-c'
and/or '-r' instances may be specified, and mixing of forward
and reverse ranges is allowed.
Is "-c M,N" identical to "-c M -c N"?
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 17:33:54 CEST