You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Paul Burba <pb...@collab.net> on 2008/01/14 19:55:17 UTC
Does a path ever need mergeinfo from itself?
On trunk, the issue-2897 branch, and reintegrate branch if we copy a
path, merge from the source to the copy, then merge from the copy back
to the source (a.k.a. a cyclic merge), then the source ends up with
mergeinfo from itself. For example, start with a vanilla greek tree:
Copy 'A' to 'A_COPY' and commit as r2:
>svn copy %url%/A merge_tests-45\A_COPY
A merge_tests-45\A_COPY\B
A merge_tests-45\A_COPY\B\lambda
A merge_tests-45\A_COPY\B\E
A merge_tests-45\A_COPY\B\E\alpha
A merge_tests-45\A_COPY\B\E\beta
A merge_tests-45\A_COPY\B\F
A merge_tests-45\A_COPY\mu
A merge_tests-45\A_COPY\C
A merge_tests-45\A_COPY\D
A merge_tests-45\A_COPY\D\gamma
A merge_tests-45\A_COPY\D\G
A merge_tests-45\A_COPY\D\G\pi
A merge_tests-45\A_COPY\D\G\rho
A merge_tests-45\A_COPY\D\G\tau
A merge_tests-45\A_COPY\D\H
A merge_tests-45\A_COPY\D\H\chi
A merge_tests-45\A_COPY\D\H\omega
A merge_tests-45\A_COPY\D\H\psi
Checked out revision 1.
A merge_tests-45\A_COPY
>svn ci -m "" merge_tests-45
Adding merge_tests-45\A_COPY
Committed revision 2.
Make a text change under 'A' and commit as r3:
>echo text change >> merge_tests-45\A\mu
>svn ci -m "" merge_tests-45
Sending merge_tests-45\A\mu
Transmitting file data .
Committed revision 3.
Merge all available changes from 'A' to 'A_COPY' and commit as r4:
>svn merge %url%/A merge_tests-45\A_COPY
--- Merging r2 through r3 into 'merge_tests-45\A_COPY':
U merge_tests-45\A_COPY\mu
Props on 'A_COPY' reflect the merge:
>svn pl -vR merge_tests-45
Properties on 'merge_tests-45\A_COPY':
svn:mergeinfo : /A:2-3
>svn ci -m "" merge_tests-45
Sending merge_tests-45\A_COPY
Sending merge_tests-45\A_COPY\mu
Transmitting file data .
Committed revision 4.
Now merge all available changes from 'A_COPY' back to 'A':
>svn merge %url%/A_COPY merge_tests-45\A
--- Merging r2 through r4 into 'merge_tests-45\A':
U merge_tests-45\A
Now we have mergeinfo for 'A' on 'A':
>svn pl -vR merge_tests-45
Properties on 'merge_tests-45\A':
svn:mergeinfo : /A:2-3
/A_COPY:2-4
Properties on 'merge_tests-45\A_COPY':
svn:mergeinfo : /A:2-3
(The resulting mergeinfo on the reintegrate branch is slightly
different):
>svn pl -vR merge_tests-45
Properties on 'merge_tests-45\A':
svn:mergeinfo : /A:2-3
/A_COPY:4
Properties on 'merge_tests-45\A_COPY':
svn:mergeinfo : /A:2-3
If we do the merge using the --reintegrate option on the reintegrate
branch things look a lot better:
>svn pl -vR merge_tests-45
Properties on 'merge_tests-45\A':
svn:mergeinfo : /A_COPY:2-4
Properties on 'merge_tests-45\A_COPY':
svn:mergeinfo : /A:2-3
Ignorning the use of --reintegrate for a moment, is there any reason we
ever need the '/A:2-3' mergeinfo on 'A' itself? Am I missing something
obvious here?
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Does a path ever need mergeinfo from itself?
Posted by "C. Michael Pilato" <cm...@collab.net>.
Paul Burba wrote:
> Ignorning the use of --reintegrate for a moment, is there any reason we
> ever need the '/A:2-3' mergeinfo on 'A' itself? Am I missing something
> obvious here?
I can't immediately think of a reason why a path would need to have
mergeinfo from its own history.
But be careful: matching paths do not overlapping histories make. You'll
need to consider the locations of your path in the merged revisions to
decide if that portion of the mergeinfo is expendable.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
RE: RE: Re: Does a path ever need mergeinfo from itself?
Posted by Kamesh Jayachandran <ka...@collab.net>.
>> Has anyone has taken on board Folker Shamel's suggestion that
>> the mergeinfo property should only contain direct merge
>> information? I think it's important to get the mergeinfo
>> property right before going any further...
>Folker has posted quite a bit regarding merge tracking recently, can you
>point to the particular post you are referring to?
I think he refers 'merge should not record indirect mergeinfo at all' i.e
We merge from /branch2, /branch3, /trunk to /branch1 at rX.
When we merge rX from /branch1 to /trunk we get 3 mergeinfo updates these spurious mergeinfo could cause future merges from /branch2 and /branch3 to
/trunk to conflict.
issue 3056 deals with this issue.
With regards
Kamesh Jayachandran
Re: Does a path ever need mergeinfo from itself?
Posted by Folker Schamel <sc...@spinor.com>.
Paul Burba wrote:
>> -----Original Message-----
>> From: news [mailto:news@ger.gmane.org] On Behalf Of Tom Widmer
>> Sent: Tuesday, January 15, 2008 12:06 PM
>> To: dev@subversion.tigris.org
>> Subject: Re: Does a path ever need mergeinfo from itself?
>>
>> ...
>> ...
>> Has anyone has taken on board Folker Shamel's suggestion that
>> the mergeinfo property should only contain direct merge
>> information? I think it's important to get the mergeinfo
>> property right before going any further...
>
> Folker has posted quite a bit regarding merge tracking recently, can you
> point to the particular post you are referring to?
http://svn.haxx.se/dev/archive-2007-12/0349.shtml
That's one small fix for today, avoiding a giant burden for the future.
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: Does a path ever need mergeinfo from itself?
Posted by Paul Burba <pb...@collab.net>.
> -----Original Message-----
> From: news [mailto:news@ger.gmane.org] On Behalf Of Tom Widmer
> Sent: Tuesday, January 15, 2008 12:06 PM
> To: dev@subversion.tigris.org
> Subject: Re: Does a path ever need mergeinfo from itself?
>
> Paul Burba wrote:
> >> -----Original Message-----
> >> From: Kamesh Jayachandran
> >> Sent: Tuesday, January 15, 2008 9:19 AM
> >> To: Paul Burba; dev@subversion.tigris.org
> >> Subject: RE: Does a path ever need mergeinfo from itself?
> >>
> >> It just comes from a prop merge, may be we can make
> >> merge_props_changed of diff callbacks to ignore mergeinfo from
> >> /target to itself.
> >
> > Thanks Kamesh,
> >
> > I was thinking the same thing. I just wanted to be sure
> that nobody
> > was relying on this mergeinfo being explicitly present (i.e. the
> > issue-2897 branch or reintegrate branch had some bizzare
> need for it
> > that was not obvious).
> >
> > Taking a look at getting rid of this (taking into account
> cmpilato's
> > warning of course).
>
> What if someone merged a range of revisions from the same
> path into that path? For example, r1 adds some changes, r2
> backs then out, r3 has conflicting but unrelated changes, but
> then they decide to merge the r1 changes back in, resolve the
> conflicts and commit as r4. In that case, should the path
> have the mergeinfo saying that r1 was merged (at r4)? It
> might be relevent information if, for example, r1 and r4 are
> cherry picked to a branch...
Hi Tom,
I not sure I completely follow your example, let me describe a more
concrete example based on what I think you are saying (apologies if I
got it all wrong, just let me know where!).
Starting with our test suite's standard greek tree (don't worry if you
aren't familiar with it, that shouldn't matter much for this example).
First we copy 'A' to 'A_BRANCH' and commit that as r2:
>svn copy %url46%/A merge_tests-46\A_BRANCH
A merge_tests-46\A_BRANCH\B
A merge_tests-46\A_BRANCH\B\lambda
A merge_tests-46\A_BRANCH\B\E
A merge_tests-46\A_BRANCH\B\E\alpha
A merge_tests-46\A_BRANCH\B\E\beta
A merge_tests-46\A_BRANCH\B\F
A merge_tests-46\A_BRANCH\mu
A merge_tests-46\A_BRANCH\C
A merge_tests-46\A_BRANCH\D
A merge_tests-46\A_BRANCH\D\gamma
A merge_tests-46\A_BRANCH\D\G
A merge_tests-46\A_BRANCH\D\G\pi
A merge_tests-46\A_BRANCH\D\G\rho
A merge_tests-46\A_BRANCH\D\G\tau
A merge_tests-46\A_BRANCH\D\H
A merge_tests-46\A_BRANCH\D\H\chi
A merge_tests-46\A_BRANCH\D\H\omega
A merge_tests-46\A_BRANCH\D\H\psi
Checked out revision 1.
A merge_tests-46\A_BRANCH
>svn ci -m "" merge_tests-46
Adding merge_tests-46\A_BRANCH
Committed revision 2.
Now we make a simple text change to 'A/mu' and commit it as r3 (which is
anlogous to your example's r1):
>echo New mu >> merge_tests-46\A\mu
>svn ci -m "" merge_tests-46
Sending merge_tests-46\A\mu
Transmitting file data .
Committed revision 3.
Then we "back out" those changes and commit as r4 (I just effectively do
this by doing an OS copy, were you thinking of doing this via merge from
'A' to 'A'?):
>copy merge_tests-46\A_BRANCH\mu merge_tests-46\A\mu
Overwrite merge_tests-46\A\mu? (Yes/No/All): y
1 file(s) copied.
>svn ci -m "" merge_tests-46
Sending merge_tests-46\A\mu
Transmitting file data .
Committed revision 4.
Now we make a 'conflicting but unrelated change' to 'A/mu' and commit as
r5:
>echo Another mu >> merge_tests-46\A\mu
>svn ci -m "" merge_tests-46
Sending merge_tests-46\A\mu
Transmitting file data .
Committed revision 5.
Now we "merge the r1(r3 in this case) changes back in, resolve the
conflicts and commit as r4(r6):
>svn merge %url46%/A merge_tests-46\A -c3
Conflict discovered in 'merge_tests-46/A/mu'.
Select: (p)ostpone, (d)iff, (e)dit, (r)esolved, (h)elp for more options
: p
--- Merging r3 into 'merge_tests-46\A':
C merge_tests-46\A\mu
>echo Resolved mu > merge_tests-46\A\mu
>svn resolved -R merge_tests-46
Resolved conflicted state of 'merge_tests-46\A\mu'
(Update 'A' to avoid Directory '/A' is out of date error):
>svn up merge_tests-46
At revision 5.
>svn ci -m "" merge_tests-46
Sending merge_tests-46\A
Sending merge_tests-46\A\mu
Transmitting file data .
Committed revision 6.
Ok, now we see mergeinfo on 'A' from itself:
>svn pl -vR merge_tests-46
Properties on 'merge_tests-46\A':
svn:mergeinfo : /A:3
Now "r1(r3) and r4(r6) are cherry picked to a branch...". Yes, we get a
conflict, but how could that be avoided based on the 'A's mergeinfo of
'/A:3'? I'm not sure how we could use that mergeinfo, in and of itself,
to avoid this conflict. Did you have something in mind specifically?
>svn merge %url46%/A merge_tests-46\A_BRANCH -c3 -c6
--- Merging r3 into 'merge_tests-46\A_BRANCH':
U merge_tests-46\A_BRANCH\mu
Conflict discovered in 'merge_tests-46/A_BRANCH/mu'.
Select: (p)ostpone, (d)iff, (e)dit, (h)elp for more options : d
--- C:\DOCUME~1\pburba\LOCALS~1\Temp/tmp Tue Jan 15 12:57:34 2008
+++ merge_tests-46/A_BRANCH/.svn/tmp/tempfile.3.tmp Tue Jan 15
12:57:34 2008
@@ -1,2 +1,6 @@
+<<<<<<< .working
This is the file 'mu'.
-Another mu
+New mu
+=======
+Resolved mu
+>>>>>>> .merge-right.r6
Select: (p)ostpone, (d)iff, (e)dit, (r)esolved, (h)elp for more options
: p
--- Merging r6 into 'merge_tests-46\A_BRANCH':
C merge_tests-46\A_BRANCH\mu
G merge_tests-46\A_BRANCH
> Has anyone has taken on board Folker Shamel's suggestion that
> the mergeinfo property should only contain direct merge
> information? I think it's important to get the mergeinfo
> property right before going any further...
Folker has posted quite a bit regarding merge tracking recently, can you
point to the particular post you are referring to?
Thanks,
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Does a path ever need mergeinfo from itself?
Posted by Tom Widmer <to...@camcog.com>.
Paul Burba wrote:
>> -----Original Message-----
>> From: Kamesh Jayachandran
>> Sent: Tuesday, January 15, 2008 9:19 AM
>> To: Paul Burba; dev@subversion.tigris.org
>> Subject: RE: Does a path ever need mergeinfo from itself?
>>
>> It just comes from a prop merge, may be we can make
>> merge_props_changed of diff callbacks to ignore mergeinfo
>> from /target to itself.
>
> Thanks Kamesh,
>
> I was thinking the same thing. I just wanted to be sure that nobody was
> relying on this mergeinfo being explicitly present (i.e. the issue-2897
> branch or reintegrate branch had some bizzare need for it that was not
> obvious).
>
> Taking a look at getting rid of this (taking into account cmpilato's
> warning of course).
What if someone merged a range of revisions from the same path into that
path? For example, r1 adds some changes, r2 backs then out, r3 has
conflicting but unrelated changes, but then they decide to merge the r1
changes back in, resolve the conflicts and commit as r4. In that case,
should the path have the mergeinfo saying that r1 was merged (at r4)? It
might be relevent information if, for example, r1 and r4 are cherry
picked to a branch...
Has anyone has taken on board Folker Shamel's suggestion that the
mergeinfo property should only contain direct merge information? I think
it's important to get the mergeinfo property right before going any
further...
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Does a path ever need mergeinfo from itself?
Posted by Paul Burba <pb...@collab.net>.
> -----Original Message-----
> From: Kamesh Jayachandran
> Sent: Tuesday, January 15, 2008 9:19 AM
> To: Paul Burba; dev@subversion.tigris.org
> Subject: RE: Does a path ever need mergeinfo from itself?
>
> It just comes from a prop merge, may be we can make
> merge_props_changed of diff callbacks to ignore mergeinfo
> from /target to itself.
Thanks Kamesh,
I was thinking the same thing. I just wanted to be sure that nobody was
relying on this mergeinfo being explicitly present (i.e. the issue-2897
branch or reintegrate branch had some bizzare need for it that was not
obvious).
Taking a look at getting rid of this (taking into account cmpilato's
warning of course).
Paul
> With regards
> Kamesh Jayachandran
>
>
> -----Original Message-----
> From: Paul Burba [mailto:pburba@collab.net]
> Sent: Tue 1/15/2008 1:25 AM
> To: dev@subversion.tigris.org
> Subject: Does a path ever need mergeinfo from itself?
>
> On trunk, the issue-2897 branch, and reintegrate branch if we
> copy a path, merge from the source to the copy, then merge
> from the copy back to the source (a.k.a. a cyclic merge),
> then the source ends up with mergeinfo from itself. For
> example, start with a vanilla greek tree:
>
> Copy 'A' to 'A_COPY' and commit as r2:
>
> >svn copy %url%/A merge_tests-45\A_COPY
> A merge_tests-45\A_COPY\B
> A merge_tests-45\A_COPY\B\lambda
> A merge_tests-45\A_COPY\B\E
> A merge_tests-45\A_COPY\B\E\alpha
> A merge_tests-45\A_COPY\B\E\beta
> A merge_tests-45\A_COPY\B\F
> A merge_tests-45\A_COPY\mu
> A merge_tests-45\A_COPY\C
> A merge_tests-45\A_COPY\D
> A merge_tests-45\A_COPY\D\gamma
> A merge_tests-45\A_COPY\D\G
> A merge_tests-45\A_COPY\D\G\pi
> A merge_tests-45\A_COPY\D\G\rho
> A merge_tests-45\A_COPY\D\G\tau
> A merge_tests-45\A_COPY\D\H
> A merge_tests-45\A_COPY\D\H\chi
> A merge_tests-45\A_COPY\D\H\omega
> A merge_tests-45\A_COPY\D\H\psi
> Checked out revision 1.
> A merge_tests-45\A_COPY
>
> >svn ci -m "" merge_tests-45
> Adding merge_tests-45\A_COPY
>
> Committed revision 2.
>
> Make a text change under 'A' and commit as r3:
>
> >echo text change >> merge_tests-45\A\mu
>
> >svn ci -m "" merge_tests-45
> Sending merge_tests-45\A\mu
> Transmitting file data .
> Committed revision 3.
>
> Merge all available changes from 'A' to 'A_COPY' and commit as r4:
>
> >svn merge %url%/A merge_tests-45\A_COPY
> --- Merging r2 through r3 into 'merge_tests-45\A_COPY':
> U merge_tests-45\A_COPY\mu
>
> Props on 'A_COPY' reflect the merge:
>
> >svn pl -vR merge_tests-45
> Properties on 'merge_tests-45\A_COPY':
> svn:mergeinfo : /A:2-3
>
> >svn ci -m "" merge_tests-45
> Sending merge_tests-45\A_COPY
> Sending merge_tests-45\A_COPY\mu
> Transmitting file data .
> Committed revision 4.
>
> Now merge all available changes from 'A_COPY' back to 'A':
>
> >svn merge %url%/A_COPY merge_tests-45\A
> --- Merging r2 through r4 into 'merge_tests-45\A':
> U merge_tests-45\A
>
> Now we have mergeinfo for 'A' on 'A':
>
> >svn pl -vR merge_tests-45
> Properties on 'merge_tests-45\A':
> svn:mergeinfo : /A:2-3
> /A_COPY:2-4
> Properties on 'merge_tests-45\A_COPY':
> svn:mergeinfo : /A:2-3
>
> (The resulting mergeinfo on the reintegrate branch is slightly
> different):
>
> >svn pl -vR merge_tests-45
> Properties on 'merge_tests-45\A':
> svn:mergeinfo : /A:2-3
> /A_COPY:4
> Properties on 'merge_tests-45\A_COPY':
> svn:mergeinfo : /A:2-3
>
> If we do the merge using the --reintegrate option on the
> reintegrate branch things look a lot better:
>
> >svn pl -vR merge_tests-45
> Properties on 'merge_tests-45\A':
> svn:mergeinfo : /A_COPY:2-4
> Properties on 'merge_tests-45\A_COPY':
> svn:mergeinfo : /A:2-3
>
>
> Ignorning the use of --reintegrate for a moment, is there any
> reason we ever need the '/A:2-3' mergeinfo on 'A' itself? Am
> I missing something obvious here?
>
> Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Does a path ever need mergeinfo from itself?
Posted by Kamesh Jayachandran <ka...@collab.net>.
It just comes from a prop merge, may be we can make merge_props_changed of diff callbacks to ignore mergeinfo from /target to itself.
With regards
Kamesh Jayachandran
-----Original Message-----
From: Paul Burba [mailto:pburba@collab.net]
Sent: Tue 1/15/2008 1:25 AM
To: dev@subversion.tigris.org
Subject: Does a path ever need mergeinfo from itself?
On trunk, the issue-2897 branch, and reintegrate branch if we copy a
path, merge from the source to the copy, then merge from the copy back
to the source (a.k.a. a cyclic merge), then the source ends up with
mergeinfo from itself. For example, start with a vanilla greek tree:
Copy 'A' to 'A_COPY' and commit as r2:
>svn copy %url%/A merge_tests-45\A_COPY
A merge_tests-45\A_COPY\B
A merge_tests-45\A_COPY\B\lambda
A merge_tests-45\A_COPY\B\E
A merge_tests-45\A_COPY\B\E\alpha
A merge_tests-45\A_COPY\B\E\beta
A merge_tests-45\A_COPY\B\F
A merge_tests-45\A_COPY\mu
A merge_tests-45\A_COPY\C
A merge_tests-45\A_COPY\D
A merge_tests-45\A_COPY\D\gamma
A merge_tests-45\A_COPY\D\G
A merge_tests-45\A_COPY\D\G\pi
A merge_tests-45\A_COPY\D\G\rho
A merge_tests-45\A_COPY\D\G\tau
A merge_tests-45\A_COPY\D\H
A merge_tests-45\A_COPY\D\H\chi
A merge_tests-45\A_COPY\D\H\omega
A merge_tests-45\A_COPY\D\H\psi
Checked out revision 1.
A merge_tests-45\A_COPY
>svn ci -m "" merge_tests-45
Adding merge_tests-45\A_COPY
Committed revision 2.
Make a text change under 'A' and commit as r3:
>echo text change >> merge_tests-45\A\mu
>svn ci -m "" merge_tests-45
Sending merge_tests-45\A\mu
Transmitting file data .
Committed revision 3.
Merge all available changes from 'A' to 'A_COPY' and commit as r4:
>svn merge %url%/A merge_tests-45\A_COPY
--- Merging r2 through r3 into 'merge_tests-45\A_COPY':
U merge_tests-45\A_COPY\mu
Props on 'A_COPY' reflect the merge:
>svn pl -vR merge_tests-45
Properties on 'merge_tests-45\A_COPY':
svn:mergeinfo : /A:2-3
>svn ci -m "" merge_tests-45
Sending merge_tests-45\A_COPY
Sending merge_tests-45\A_COPY\mu
Transmitting file data .
Committed revision 4.
Now merge all available changes from 'A_COPY' back to 'A':
>svn merge %url%/A_COPY merge_tests-45\A
--- Merging r2 through r4 into 'merge_tests-45\A':
U merge_tests-45\A
Now we have mergeinfo for 'A' on 'A':
>svn pl -vR merge_tests-45
Properties on 'merge_tests-45\A':
svn:mergeinfo : /A:2-3
/A_COPY:2-4
Properties on 'merge_tests-45\A_COPY':
svn:mergeinfo : /A:2-3
(The resulting mergeinfo on the reintegrate branch is slightly
different):
>svn pl -vR merge_tests-45
Properties on 'merge_tests-45\A':
svn:mergeinfo : /A:2-3
/A_COPY:4
Properties on 'merge_tests-45\A_COPY':
svn:mergeinfo : /A:2-3
If we do the merge using the --reintegrate option on the reintegrate
branch things look a lot better:
>svn pl -vR merge_tests-45
Properties on 'merge_tests-45\A':
svn:mergeinfo : /A_COPY:2-4
Properties on 'merge_tests-45\A_COPY':
svn:mergeinfo : /A:2-3
Ignorning the use of --reintegrate for a moment, is there any reason we
ever need the '/A:2-3' mergeinfo on 'A' itself? Am I missing something
obvious here?
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org