> -----Original Message-----
> From: news [mailto:news_at_ger.gmane.org] On Behalf Of Tom Widmer
> Sent: Tuesday, January 15, 2008 12:06 PM
> To: dev_at_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_at_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_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-15 19:41:19 CET