You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Jens Seidel <je...@users.sourceforge.net> on 2008/06/05 15:53:35 UTC
Bug during (interactive) merging?
Hi,
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
If I merge first the renaming and after it the removal (without
intermediate commit) I get:
M .
D file
A + file.old
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?
Jens
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug during (interactive) merging?
Posted by Jens Seidel <je...@users.sourceforge.net>.
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 <je...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug during (interactive) merging?
Posted by Paul Burba <pt...@gmail.com>.
On Tue, Jun 10, 2008 at 11:29 AM, Jens Seidel <je...@users.sf.net> wrote:
> 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"!
At one point in the development the following were all equivalent:
svn merge [-c8,9 | -r7:8 -r 8:9 | -r7:9]
We made some assumptions about what the user wanted when multiple
ranges/revisions were specified and tried to compact and sort the
requested revs/ranges. But after some discussion - see
http://svn.haxx.se/dev/archive-2008-01/0091.shtml - it was decided
that the compaction logic should be removed (see r28871 and r28872).
The upshot of this is that when specifying multiple revisions/ranges,
that merge does exactly what you ask, in the order you ask, and the
end result should be the same as if you did individual merges *in that
order*, e.g.:
'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: 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):
>svn log -v -r9:10
------------------------------------------------------------------------
r9 | pburba | 2008-06-10 11:52:17 -0400 (Tue, 10 Jun 2008) | 1 line
Changed paths:
D /A/C/nu
A /A/C/nu_renamed (from /A/C/nu:8)
------------------------------------------------------------------------
r10 | pburba | 2008-06-10 11:52:33 -0400 (Tue, 10 Jun 2008) | 1 line
Changed paths:
D /A/C/nu_renamed
------------------------------------------------------------------------
>svn merge %url%/A A_COPY -c9
--- Merging r9 into 'A_COPY':
A A_COPY\C\nu_renamed
D A_COPY\C\nu
>svn st
M A_COPY
D A_COPY\C\nu
A + A_COPY\C\nu_renamed
>svn merge %url%/A A_COPY -c10
Skipped 'A_COPY\C\nu_renamed'
>svn st
M A_COPY
D A_COPY\C\nu
A + A_COPY\C\nu_renamed
If you reverted and tried the merge again with --force I expect you'll
see what you expect:
>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
without --force doesn't have a notification header for the merge of
r10 since all paths were skipped (I know this was done on purpose, but
can't find the thread).
>> 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?
So yeah, it does matter. Don't really think it is a bug though.
The bug I do see is in the way mergeinfo is set when doing the merges
separately or with -cX,Y. Looking back of my first example the merge
of c10 skips 'A_COPY\C\nu_renamed'. That's ok, but the mergeinfo set
on the merge target 'A_COPY' makes it look like there merge really
occurred!
>svn merge %url99%/A A_COPY -c9
--- Merging r9 into 'A_COPY':
A A_COPY\C\nu_renamed
D A_COPY\C\nu
>svn merge %url99%/A A_COPY -c10
Skipped 'A_COPY\C\nu_renamed'
>svn pl A_COPY -v
Properties on 'A_COPY':
svn:mergeinfo : /A:9-10
'A_COPY' now has mergeinfo for r10, so this prevents a repeat merge
attempt of r10 from doing anything:
>svn merge %url99%/A A_COPY -c10
Ok then we'll try --force, but that does nothing since the mergeinfo
thwarts the repeat merge attempt anyway:
>svn merge %url99%/A A_COPY -c10 --force
Oh wait, --ignore-ancestry will cause the mergeinfo to be disregarded:
>svn merge %url99%/A A_COPY -c10 --ignore-ancestry
Skipped 'A_COPY\C\nu_renamed'
Still nothing...we need both --force and --ignore-ancestry to make the
repeat merge happen and actually delete the path scheduled for
addition with history!
>svn merge %url99%/A A_COPY -c10 --ignore-ancestry --force
--- Merging r10 into 'A_COPY':
D A_COPY\C\nu_renamed
Ugh, I could just scream. I think we might need to reopen issue #2829...
>> 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"?
Those are the same yes.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug during (interactive) merging?
Posted by Jens Seidel <je...@users.sourceforge.net>.
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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New SVNSYNC bug?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Thu, Jun 5, 2008 at 7:54 PM, David Summers
<da...@summersoft.fay.ar.us> wrote:
> The only difference I can see is that I did a dump/load instead of upgrading
> a pre-1.5.0 slave repository in-place from subversion-1.5.0-r27613 from
> 2007-11 to the new 1.5.0-rc[8,9].
>
> If Justin Erenkrantz, who was also seeing this same effect, gets a chance,
> maybe he can do the same thing and see if that "fixes" it.
We (apache.org) upgraded both ends to 1.5.x and it went away. So, I'd
be suspect about 1.5 clients talking to 1.4 servers. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New SVNSYNC bug?
Posted by David Summers <da...@summersoft.fay.ar.us>.
Just as a follow-up to anyone interested.
The wierd svnsync corruption I reported back on 2008-04-28 is now
apparently gone.
I was actually seeing the corruption every once in a while the last
few days with my supposedly "stable" subversion-1.5.0-r27613 from 2007-11,
so....
The other day I did a svnadmin dump/load on all my slave repositories to
subversion-1.5.0-rc8 (and upgraded today to rc9) and so far I have seen
none of the wierd corruption reported on any of them (I commited 5 - 10
times on several of them today).
The only difference I can see is that I did a dump/load instead of
upgrading a pre-1.5.0 slave repository in-place from
subversion-1.5.0-r27613 from 2007-11 to the new
1.5.0-rc[8,9].
If Justin Erenkrantz, who was also seeing this same effect, gets a chance,
maybe he can do the same thing and see if that "fixes" it.
I've been using the 1.5.0 pre-rc? versions since 2006/12 with just a
couple of problems and only used several different versions during that
time, so it was pretty stable until 2008-04-28 for some reason.
Anyway, hopefully we won't see any of that again.
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@summersoft.fay.ar.us PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint = 0B44 B118 85CC F4EC 7021 1ED4 1516 5B78 E320 2001
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org