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

Re: Bug during (interactive) merging?

From: Jens Seidel <jensseidel_at_users.sourceforge.net>
Date: Tue, 10 Jun 2008 17:29:39 +0200

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

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.