[prev in list] [next in list] [prev in thread] [next in thread]
List: subversion-dev
Subject: Re: Problems Reintegrating the fsfs-format7 branch (Was: FSFS format7 status and first results)
From: Stefan Fuhrmann <stefan.fuhrmann () wandisco ! com>
Date: 2013-02-27 22:27:26
Message-ID: CA+t0gk0nk28YdFf6H5jwqFD7Ft1pzqpz-xgRZLTpdunM90ccHw () mail ! gmail ! com
[Download RAW message or body]
On Wed, Feb 27, 2013 at 10:21 PM, Paul Burba <ptburba@gmail.com> wrote:
> (Stefan - If you don't have time to read all this please at least take
> a look at the short questions at the very end)
>
No worries :) Thanks for digging into this problem.
General remark: I'm working at and committing from my
Ubuntu 12.04 laptop since mid January and will continue
to do so until Easter. That means: Subversion 1.6.17.
> On Mon, Feb 18, 2013 at 11:54 AM, Mark Phippard <markphip@gmail.com>
> wrote:
>
> > BTW, how are you managing your branch? I tried merging it back to
> > trunk to get an idea on the diff and there were a lot of text and tree
> > conflicts. I thought I had seen you doing synch merges from trunk in
> > the past so I assumed it would merge back.
>
> On Thu, Feb 21, 2013 at 5:05 AM, Stefan Fuhrmann
> <stefan.fuhrmann@wandisco.com> wrote:
>
> > Hm. I split fsfs.c and .h into multiple files on the
> > branch and the first merge from /trunk required
> > significant manual intervention. Since that, merges
> > have been clean because fsfs.* wasn't touched
> > on /trunk.
> >
> > If I understand Julian's merge changes in 1.8,
> > reintegrating should work because there has been
> > no cherry picking etc.
>
> On Thu, Feb 21, 2013 at 11:04 AM, Mark Phippard <markphip@gmail.com>
> wrote:
>
> > I see this when using 1.8:
> >
> > $ svn mergeinfo ^/subversion/branches/fsfs-format7
> > youngest common ancestor
> > | last full merge
> > | | tip of branch
> > | | | repository path
> >
> > 1414755 1448697
> > | |
> > --| |------------ subversion/branches/fsfs-format7
> > /
> > /
> > -------| |------------ subversion/trunk
> > |
> > 1447423
> >
> > It seems to imply that it does not think you have ever synched with
> > trunk. So maybe it is trying to replay every revision from your
> > branch when I merge back and that is why it gets so many conflicts?
>
> I found the cause of the conflict filled reintegrate merge. The
> automatic merge code seems to be doing the right thing re Mark's
> automatic merge above, the problem arises earlier.
>
> First, here is the relationship between the two branches in question:
>
> trunk@1414755------------@1442089---@r1445080------------>
> | | | ^
> copy sync sync |
> | merge merge conflict-filled
> | | | automatic
> | | | merge
> | | | |
> V V V |
> fsfs-format7@1414757---r1442344---r1445479------------>
>
> The first problem is that the "sync" merge in r1442344 recorded the
> wrong mergeinfo:
>
> >svn log ^^/subversion/branches/fsfs-format7 -r1442344
> ------------------------------------------------------------------------
> r1442344 | stefan2 | 2013-02-04 15:48:05 -0500 (Mon, 04 Feb 2013) | 2 lines
>
> On the fsfs-format7: ketchup merge from /trunk up to and including
> r1442089.
> Some conflicts due to splitting up fs_fs.c needed to be resolved.
> ------------------------------------------------------------------------
>
> >svn diff --depth empty ^^/subversion/branches/fsfs-format7 -c1442344
> Index: .
> ===================================================================
> --- . (revision 1442343)
> +++ . (revision 1442344)
>
> Property changes on: .
> ___________________________________________________________________
> Modified: svn:ignore
> ## -49,3 +49,6 ##
> zlib
> sqlite-amalgamation
> serf
> +gtest
> +.git
> +.gitignore
> Modified: svn:mergeinfo
> Merged /subversion/branches/issue-4116-dev:r1424719-1425040
> Merged /subversion/trunk:r1414758-1442089
> ^^^^^^^
> Why not r1414756?
> That is the first revision on trunk after
> the branch was created.
>
I simply didn't notice it, so I wrongly assumed at the
branch was created from 1414756. Don't remember
which tool I used to created the repo-repo copy to
open the branch.
Merged
> /subversion/branches/tweak-build-take-two:r1424288-1425049,1425051-1425613
> Merged /subversion/branches/in-repo-authz:r1414342-1424779
> Merged /subversion/branches/issue-4194-dev:r1410507-1414880
> Merged /subversion/branches/wc-collate-path:r1407642
>
> The mergeinfo recorded makes it look like a big cherrypick of
> r1414758-1442089 was done from ^/subversion/trunk to
> ^/subversion/branches/fsfs-format7, rather than a proper sync merge.
> Well, not to worry, the subsequent sync merge committed in r1445479
> will notice that /subversion/trunk:r1414756-1414757 has *not* been
> merged and merge those missing revisions -- they are inoperative but
> that doesn't matter, the mergeinfo should still be recorded. Except
> that didn't happen either:
>
That is no surprise as I merged (lastmerge+1):headRev.
>svn diff --depth empty ^^/subversion/branches/fsfs-format7 -c1445479
> Index: .
> ===================================================================
> --- . (revision 1445478)
> +++ . (revision 1445479)
>
> Property changes on: .
> ___________________________________________________________________
> Modified: svn:mergeinfo
> Merged /subversion/trunk:r1442090-1445080
>
> So why is this a problem? Because later, when we try to merge the
> branch back to trunk, the automatic merge code is trying to determine
> if it is dealing with a "sync" or "reintegrate" style merge, it sees
> that there is a gap in the mergeinfo on the source branch (i.e.
> /subversion/trunk:r1414756-1414757) that makes it appear that the
> branch is *not* fully in sync with the trunk. Not-in-sync means no
> reintegrate-style merge, but rather a normal sync style merge, which
> (just like 1.7 if the --reintegrate option isn't used) doesn't do what
> we want. It tries to merge all of the branches changes, resulting in
> dozens of tree conflicts.
>
Why doesn't the merge code recognize r1414756 as inconsequential?
So that is the cause of the problem Mark observed, but why did the
> sync merges Stefan performed in r1442344 and 1445479 do the wrong
> thing? Repeating those two offending merges I am not able to
> replicate the faulty mergeinfo in either case:
>
> The first sync merge done in r1442344:
>
> C:\SVN\src-branch-fsfs-format7>svn info
> Path: .
> Working Copy Root Path: C:\SVN\src-branch-fsfs-format7
> URL: https://svn.apache.org/repos/asf/subversion/branches/fsfs-format7
> Relative URL: ^/subversion/branches/fsfs-format7
> Repository Root: https://svn.apache.org/repos/asf
> Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
> Revision: 1442343
> Node Kind: directory
> Schedule: normal
> Last Changed Author: stefan2
> Last Changed Rev: 1442081
> Last Changed Date: 2013-02-04 06:27:56 -0500 (Mon, 04 Feb 2013)
>
> C:\SVN\src-branch-fsfs-format7>svn st
>
> C:\SVN\src-branch-fsfs-format7>svn merge ^^/subversion/trunk . --accept
> postpone
> --- Merging r1414756 through r1450917 into '.':
> U get-deps.sh
> U Makefile.in
> U build.conf
> .
> <SNIP>
> .
> U autogen.sh
> U aclocal.m4
> D packages
> U .
> --- Recording mergeinfo for merge of r1414756 through r1450917 into '.':
> G .
> Summary of conflicts:
> Text conflicts: 5
> Tree conflicts: 1
>
> C:\SVN\src-branch-fsfs-format7>svn diff --depth empty
> Index: .
> ===================================================================
> --- . (revision 1442343)
> +++ . (working copy)
>
> Property changes on: .
> ___________________________________________________________________
> Modified: svn:mergeinfo
> Merged /subversion/branches/issue-4116-dev:r1424719-1425040
> Merged /subversion/trunk:r1414756-1450917
> ^^^^^^^
> That's right! The mergeinfo picks up right
> after the yca.
> Merged
> /subversion/branches/tweak-build-take-two:r1424288-1425049,1425051-1425613
> Merged /subversion/branches/in-repo-authz:r1414342-1424779
> Merged /subversion/branches/issue-4194-dev:r1410507-1414880
> Merged /subversion/branches/wc-collate-path:r1407642
> Modified: svn:ignore
> ## -49,3 +49,6 ##
> zlib
> sqlite-amalgamation
> serf
> +gtest
> +.git
> +.gitignore
>
>
> The second merge in r1445479, which should have filled in the
> mergeinfo gap, also works when I tried it:
>
> C:\SVN\src-branch-fsfs-format7>svn info
> Path: .
> Working Copy Root Path: C:\SVN\src-branch-fsfs-format7
> URL: https://svn.apache.org/repos/asf/subversion/branches/fsfs-format7
> Relative URL: ^/subversion/branches/fsfs-format7
> Repository Root: https://svn.apache.org/repos/asf
> Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
> Revision: 1445478
> Node Kind: directory
> Schedule: normal
> Last Changed Author: stefan2
> Last Changed Rev: 1445080
> Last Changed Date: 2013-02-12 05:02:13 -0500 (Tue, 12 Feb 2013)
>
>
> C:\SVN\src-branch-fsfs-format7>svn st
>
> C:\SVN\src-branch-fsfs-format7>svn merge ^^/subversion/trunk --accept
> postpone
> --- Merging r1442090 through r1450954 into '.':
> U get-deps.sh
> U Makefile.in
> U build.conf
> .
> <SNIP>
> .
> U INSTALL
> U CHANGES
> D packages
> --- Recording mergeinfo for merge of r1414756 through r1450954 into '.':
> U .
> Summary of conflicts:
> Text conflicts: 1
>
> C:\SVN\src-branch-fsfs-format7>svn diff --depth empty
> Index: .
> ===================================================================
> --- . (revision 1445478)
> +++ . (working copy)
>
> Property changes on: .
> ___________________________________________________________________
> Modified: svn:mergeinfo
> Merged /subversion/trunk:r1414756-1414757,1442090-1450954
> ^^^^^^^^^^^^^^^
> The gap is plugged!
>
> So what happened? There are a few options that I can see:
>
> 1) Transient mergeinfo recording bug that afflicted the client that
> Stefan used to do the merges (I don't recall anything like this
> recently and this is pretty basic stuff that has been in place since
> 1.6).
>
Used 1.6.17. But that does not seem to be the root cause:
$ /usr/bin/svn merge ^/subversion/trunk .
--- Merging r1445081 through r1450992 into '.':
^^^^
So, it recognizes that r1414756 as inconsequential.
U get-deps.sh
... gazillion changes and a conflict on fs_fs.c ...
$ /usr/bin/svn pl -v | grep "trunk"
/subversion/trunk:1414756-1450992
The mergeinfo now covers r1414756 as well.
2) Stefan didn't actually do a sync merge, but rather did a cherry
> pick, e.g. 'svn merge ^/subversion/trunk branch-wc -r1414757:HEAD'.
> Stefan - do you recall how you did these merges? How about what
> client version you used? Did you use --allow-mixed-revisions by
> chance
>
The client that I used will always send revision ranges
to the SVN libs and that is the trigger of what we are
seeing here. So, yes, technically, a cherry pick as in
"picking all cherries that there are".
I guess the question is why we make that a user problem.
The user (me) intended to merge all changes from /trunk
to the branch and told svn where to find these. The fact
that SVN gets confused by completely unrelated changes
not being listed explicitly is a tool (SVN) problem.
3) Some as of yet undiscovered bug
>
Only a usability issue.
> P.S. Stefan, In the meantime I suggest you do the following record
> only merge to plug the gap, so when your branch is ultimately merged
> back to trunk it will be possible via a simple automatic merge:
>
> svn merge ^/subversion/trunk --record-only -r1414755:1414757
>
Done in r1451004.
-- Stefan^2.
--
Certified & Supported Apache Subversion Downloads:
*
http://www.wandisco.com/subversion/download
*
[Attachment #3 (text/html)]
<div class="gmail_quote">On Wed, Feb 27, 2013 at 10:21 PM, Paul Burba <span \
dir="ltr"><<a href="mailto:ptburba@gmail.com" \
target="_blank">ptburba@gmail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> (Stefan - If you don't have time to read all this please \
at least take<br> a look at the short questions at the very \
end)<br></blockquote><div><br>No worries :) Thanks for digging into this \
problem.<br><br>General remark: I'm working at and committing from my<br>Ubuntu \
12.04 laptop since mid January and will continue<br> to do so until Easter. That \
means: Subversion 1.6.17.<br> <br></div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Mon, Feb \
18, 2013 at 11:54 AM, Mark Phippard <<a \
href="mailto:markphip@gmail.com">markphip@gmail.com</a>> wrote:<br> <br>
> BTW, how are you managing your branch? I tried merging it back to<br>
> trunk to get an idea on the diff and there were a lot of text and tree<br>
> conflicts. I thought I had seen you doing synch merges from trunk in<br>
> the past so I assumed it would merge back.<br>
<br>
On Thu, Feb 21, 2013 at 5:05 AM, Stefan Fuhrmann<br>
<<a href="mailto:stefan.fuhrmann@wandisco.com">stefan.fuhrmann@wandisco.com</a>> \
wrote:<br> <br>
> Hm. I split fsfs.c and .h into multiple files on the<br>
> branch and the first merge from /trunk required<br>
> significant manual intervention. Since that, merges<br>
> have been clean because fsfs.* wasn't touched<br>
> on /trunk.<br>
><br>
> If I understand Julian's merge changes in 1.8,<br>
> reintegrating should work because there has been<br>
> no cherry picking etc.<br>
<br>
On Thu, Feb 21, 2013 at 11:04 AM, Mark Phippard <<a \
href="mailto:markphip@gmail.com">markphip@gmail.com</a>> wrote:<br> <br>
> I see this when using 1.8:<br>
><br>
> $ svn mergeinfo ^/subversion/branches/fsfs-format7<br>
> youngest common ancestor<br>
> | last full merge<br>
> | | tip of branch<br>
> | | | repository path<br>
><br>
> 1414755 1448697<br>
> | |<br>
> --| |------------ subversion/branches/fsfs-format7<br>
> /<br>
> /<br>
> -------| |------------ subversion/trunk<br>
> |<br>
> 1447423<br>
><br>
> It seems to imply that it does not think you have ever synched with<br>
> trunk. So maybe it is trying to replay every revision from your<br>
> branch when I merge back and that is why it gets so many conflicts?<br>
<br>
I found the cause of the conflict filled reintegrate merge. The<br>
automatic merge code seems to be doing the right thing re Mark's<br>
automatic merge above, the problem arises earlier.<br>
<br>
First, here is the relationship between the two branches in question:<br>
<br>
trunk@1414755------------@1442089---@r1445080------------><br>
| | | ^<br>
copy sync sync |<br>
| merge merge conflict-filled<br>
| | | automatic<br>
| | | merge<br>
| | | |<br>
V V V |<br>
fsfs-format7@1414757---r1442344---r1445479------------><br>
<br>
The first problem is that the "sync" merge in r1442344 recorded the<br>
wrong mergeinfo:<br>
<br>
>svn log ^^/subversion/branches/fsfs-format7 -r1442344<br>
------------------------------------------------------------------------<br>
r1442344 | stefan2 | 2013-02-04 15:48:05 -0500 (Mon, 04 Feb 2013) | 2 lines<br>
<br>
On the fsfs-format7: ketchup merge from /trunk up to and including r1442089.<br>
Some conflicts due to splitting up fs_fs.c needed to be resolved.<br>
------------------------------------------------------------------------<br>
<br>
>svn diff --depth empty ^^/subversion/branches/fsfs-format7 -c1442344<br>
Index: .<br>
===================================================================<br>
--- . (revision 1442343)<br>
+++ . (revision 1442344)<br>
<br>
Property changes on: .<br>
___________________________________________________________________<br>
Modified: svn:ignore<br>
## -49,3 +49,6 ##<br>
zlib<br>
sqlite-amalgamation<br>
serf<br>
+gtest<br>
+.git<br>
+.gitignore<br>
Modified: svn:mergeinfo<br>
Merged /subversion/branches/issue-4116-dev:r1424719-1425040<br>
Merged /subversion/trunk:r1414758-1442089<br>
^^^^^^^<br>
Why not r1414756?<br>
That is the first revision on trunk after<br>
the branch was created.<br></blockquote><div><br>I \
simply didn't notice it, so I wrongly assumed at the<br>branch was created from \
1414756. Don't remember<br>which tool I used to created the repo-repo copy to<br> \
open the branch.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> Merged \
/subversion/branches/tweak-build-take-two:r1424288-1425049,1425051-1425613<br> \
Merged /subversion/branches/in-repo-authz:r1414342-1424779<br> Merged \
/subversion/branches/issue-4194-dev:r1410507-1414880<br> Merged \
/subversion/branches/wc-collate-path:r1407642<br> <br>
The mergeinfo recorded makes it look like a big cherrypick of<br>
r1414758-1442089 was done from ^/subversion/trunk to<br>
^/subversion/branches/fsfs-format7, rather than a proper sync merge.<br>
Well, not to worry, the subsequent sync merge committed in r1445479<br>
will notice that /subversion/trunk:r1414756-1414757 has *not* been<br>
merged and merge those missing revisions -- they are inoperative but<br>
that doesn't matter, the mergeinfo should still be recorded. Except<br>
that didn't happen either:<br></blockquote><div><br>That is no surprise as I \
merged (lastmerge+1):headRev.<br><br></div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>svn diff --depth empty ^^/subversion/branches/fsfs-format7 -c1445479<br>
Index: .<br>
===================================================================<br>
--- . (revision 1445478)<br>
+++ . (revision 1445479)<br>
<br>
Property changes on: .<br>
___________________________________________________________________<br>
Modified: svn:mergeinfo<br>
Merged /subversion/trunk:r1442090-1445080<br>
<br>
So why is this a problem? Because later, when we try to merge the<br>
branch back to trunk, the automatic merge code is trying to determine<br>
if it is dealing with a "sync" or "reintegrate" style merge, it \
sees<br> that there is a gap in the mergeinfo on the source branch (i.e.<br>
/subversion/trunk:r1414756-1414757) that makes it appear that the<br>
branch is *not* fully in sync with the trunk. Not-in-sync means no<br>
reintegrate-style merge, but rather a normal sync style merge, which<br>
(just like 1.7 if the --reintegrate option isn't used) doesn't do what<br>
we want. It tries to merge all of the branches changes, resulting in<br>
dozens of tree conflicts.<br></blockquote><div><br>Why doesn't the merge code \
recognize r1414756 as inconsequential?<br><br></div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So that is the cause of the problem Mark observed, but why did the<br>
sync merges Stefan performed in r1442344 and 1445479 do the wrong<br>
thing? Repeating those two offending merges I am not able to<br>
replicate the faulty mergeinfo in either case:<br>
<br>
The first sync merge done in r1442344:<br>
<br>
C:\SVN\src-branch-fsfs-format7>svn info<br>
Path: .<br>
Working Copy Root Path: C:\SVN\src-branch-fsfs-format7<br>
URL: <a href="https://svn.apache.org/repos/asf/subversion/branches/fsfs-format7" \
target="_blank">https://svn.apache.org/repos/asf/subversion/branches/fsfs-format7</a><br>
Relative URL: ^/subversion/branches/fsfs-format7<br>
Repository Root: <a href="https://svn.apache.org/repos/asf" \
target="_blank">https://svn.apache.org/repos/asf</a><br> Repository UUID: \
13f79535-47bb-0310-9956-ffa450edef68<br>
Revision: 1442343<br>
Node Kind: directory<br>
Schedule: normal<br>
Last Changed Author: stefan2<br>
Last Changed Rev: 1442081<br>
Last Changed Date: 2013-02-04 06:27:56 -0500 (Mon, 04 Feb 2013)<br>
<br>
C:\SVN\src-branch-fsfs-format7>svn st<br>
<br>
C:\SVN\src-branch-fsfs-format7>svn merge ^^/subversion/trunk . --accept \
postpone<br>
--- Merging r1414756 through r1450917 into '.':<br>
U get-deps.sh<br>
U Makefile.in<br>
U build.conf<br>
.<br>
<SNIP><br>
.<br>
U autogen.sh<br>
U aclocal.m4<br>
D packages<br>
U .<br>
--- Recording mergeinfo for merge of r1414756 through r1450917 into '.':<br>
G .<br>
Summary of conflicts:<br>
Text conflicts: 5<br>
Tree conflicts: 1<br>
<br>
C:\SVN\src-branch-fsfs-format7>svn diff --depth empty<br>
Index: .<br>
===================================================================<br>
--- . (revision 1442343)<br>
+++ . (working copy)<br>
<br>
Property changes on: .<br>
___________________________________________________________________<br>
Modified: svn:mergeinfo<br>
Merged /subversion/branches/issue-4116-dev:r1424719-1425040<br>
Merged /subversion/trunk:r1414756-1450917<br>
^^^^^^^<br>
That's right! The mergeinfo picks up right<br>
after the yca.<br>
Merged /subversion/branches/tweak-build-take-two:r1424288-1425049,1425051-1425613<br>
Merged /subversion/branches/in-repo-authz:r1414342-1424779<br>
Merged /subversion/branches/issue-4194-dev:r1410507-1414880<br>
Merged /subversion/branches/wc-collate-path:r1407642<br>
Modified: svn:ignore<br>
## -49,3 +49,6 ##<br>
zlib<br>
sqlite-amalgamation<br>
serf<br>
+gtest<br>
+.git<br>
+.gitignore<br>
<br>
<br>
The second merge in r1445479, which should have filled in the<br>
mergeinfo gap, also works when I tried it:<br>
<br>
C:\SVN\src-branch-fsfs-format7>svn info<br>
Path: .<br>
Working Copy Root Path: C:\SVN\src-branch-fsfs-format7<br>
URL: <a href="https://svn.apache.org/repos/asf/subversion/branches/fsfs-format7" \
target="_blank">https://svn.apache.org/repos/asf/subversion/branches/fsfs-format7</a><br>
Relative URL: ^/subversion/branches/fsfs-format7<br>
Repository Root: <a href="https://svn.apache.org/repos/asf" \
target="_blank">https://svn.apache.org/repos/asf</a><br> Repository UUID: \
13f79535-47bb-0310-9956-ffa450edef68<br>
Revision: 1445478<br>
Node Kind: directory<br>
Schedule: normal<br>
Last Changed Author: stefan2<br>
Last Changed Rev: 1445080<br>
Last Changed Date: 2013-02-12 05:02:13 -0500 (Tue, 12 Feb 2013)<br>
<br>
<br>
C:\SVN\src-branch-fsfs-format7>svn st<br>
<br>
C:\SVN\src-branch-fsfs-format7>svn merge ^^/subversion/trunk --accept postpone<br>
--- Merging r1442090 through r1450954 into '.':<br>
U get-deps.sh<br>
U Makefile.in<br>
U build.conf<br>
.<br>
<SNIP><br>
.<br>
U INSTALL<br>
U CHANGES<br>
D packages<br>
--- Recording mergeinfo for merge of r1414756 through r1450954 into '.':<br>
U .<br>
Summary of conflicts:<br>
Text conflicts: 1<br>
<br>
C:\SVN\src-branch-fsfs-format7>svn diff --depth empty<br>
Index: .<br>
===================================================================<br>
--- . (revision 1445478)<br>
+++ . (working copy)<br>
<br>
Property changes on: .<br>
___________________________________________________________________<br>
Modified: svn:mergeinfo<br>
Merged /subversion/trunk:r1414756-1414757,1442090-1450954<br>
^^^^^^^^^^^^^^^<br>
The gap is plugged!<br>
<br>
So what happened? There are a few options that I can see:<br>
<br>
1) Transient mergeinfo recording bug that afflicted the client that<br>
Stefan used to do the merges (I don't recall anything like this<br>
recently and this is pretty basic stuff that has been in place since<br>
1.6).<br></blockquote><div><br>Used 1.6.17. But that does not seem to be the root \
cause:<br> <br></div><div>$ /usr/bin/svn merge ^/subversion/trunk .<br>--- Merging \
r1445081 through r1450992 into '.':<br> ^^^^<br> So, it \
recognizes that r1414756 as inconsequential.<br>U get-deps.sh<br>
... gazillion changes and a conflict on fs_fs.c ...<br><br>$ /usr/bin/svn pl -v | \
grep "trunk"<br> /subversion/trunk:1414756-1450992<br><br>The mergeinfo \
now covers r1414756 as well.<br><br></div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) Stefan didn't actually do a sync merge, but rather did a cherry<br>
pick, e.g. 'svn merge ^/subversion/trunk branch-wc -r1414757:HEAD'.<br>
Stefan - do you recall how you did these merges? How about what<br>
client version you used? Did you use --allow-mixed-revisions by<br>
chance<br></blockquote><div><br>The client that I used will always send revision \
ranges<br>to the SVN libs and that is the trigger of what we are<br>seeing here. So, \
yes, technically, a cherry pick as in<br>"picking all cherries that there \
are".<br> <br>I guess the question is why we make that a user problem.<br>The \
user (me) intended to merge all changes from /trunk<br>to the branch and told svn \
where to find these. The fact<br>that SVN gets confused by completely unrelated \
changes<br> not being listed explicitly is a tool (SVN) \
problem.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> 3) Some as of yet undiscovered \
bug<br> <span class="HOEnZb"><font \
color="#888888"></font></span></blockquote><div><br>Only a usability issue.<br> \
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
P.S. Stefan, In the meantime I suggest you do the following record<br>
only merge to plug the gap, so when your branch is ultimately merged<br>
back to trunk it will be possible via a simple automatic merge:<br>
<br>
svn merge ^/subversion/trunk --record-only -r1414755:1414757<br>
</font></span></blockquote></div><br>Done in r1451004.<br><br>-- Stefan^2.<br \
clear="all"><br>-- <br><font>Certified & Supported Apache Subversion \
Downloads:<br></font><i><p \
style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:Cambria">
<font><a href="http://www.wandisco.com/subversion/download" \
target="_blank">http://www.wandisco.com/subversion/download</a></font><br> </p></i>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic