You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Andrew Reedick <An...@cbeyond.net> on 2014/01/16 21:31:39 UTC
"svn log --xml -g" doesn't identify a reverse merge but "svn log
-g" does
I need a sanity check. Is this an oversight that needs to be corrected, or am I missing something?
Problem:
"svn log -g" will explicitly identify a reverse merge, however, when specifying xml output ("svn log -g --xml") no such identification is made.
Example:
In this case, r13 on branches/test was merged to trunk (which created r15 on trunk.) I then reverse merged the r13 change out of trunk using "svn merge -c -15".
a) "svn log -g -v" explicitly states that r13 was "Reverse merged via..":
------------------------------------------------------------------------
r17 | andrew | 2014-01-16 14:41:15 -0500 (Thu, 16 Jan 2014) | 1 line
Changed paths:
M /trunk
M /trunk/a.txt
svn merge -c -15 .
------------------------------------------------------------------------
r13 | andrew | 2014-01-16 14:37:17 -0500 (Thu, 16 Jan 2014) | 1 line
Changed paths:
M /branches/test/a.txt
==> Reverse merged via: r17
branch 3
------------------------------------------------------------------------
b) However, "svn log -g -v --xml" does not indicate that it was a reverse merge:
<logentry revision="17">
<author>andrew</author>
<date>2014-01-16T19:41:15.571931Z</date>
<paths>
<path
action="M"
prop-mods="true"
text-mods="false"
kind="dir">/trunk</path>
<path
action="M"
prop-mods="false"
text-mods="true"
kind="file">/trunk/a.txt</path>
</paths>
<msg>svn merge -c -15 .</msg>
==> <logentry revision="13">
<author>andrew</author>
<date>2014-01-16T19:37:17.531316Z</date>
<paths>
<path
text-mods="true"
kind="file"
action="M"
prop-mods="false">/branches/test/a.txt</path>
</paths>
<msg>branch 3</msg>
</logentry>
</logentry>
Andrew Reedick
CBeyond
Cloud Development, SCM
O: 678.486.8163
Re: "svn log --xml -g" doesn't identify a reverse merge but "svn
log -g" does
Posted by Ben Reser <be...@reser.org>.
On 1/16/14, 1:59 PM, Ben Reser wrote:
> Opened issue #4463 for this:
> http://subversion.tigris.org/issues/show_bug.cgi?id=4463
Fixed in r1559032. I anticipate that the fix will be included in 1.9.0.
Re: "svn log --xml -g" doesn't identify a reverse merge but "svn
log -g" does
Posted by Ben Reser <be...@reser.org>.
On 1/16/14, 1:38 PM, Ben Reser wrote:
> On 1/16/14, 12:31 PM, Andrew Reedick wrote:
>> I need a sanity check. Is this an oversight that needs to be corrected, or am I missing something?
>>
>> Problem:
>> "svn log -g" will explicitly identify a reverse merge, however, when specifying xml output ("svn log -g --xml") no such identification is made.
>
> Yup looks like an oversight. The nesting already shows that it's a merge and
> what revision made the merge. But we don't show the direction of the merge.
>
> I've coded up a trivial change to add a reverse-merge attribute on the logentry
> element in this case. e.g.
> <logentry revision="13" reverse-merge="true">
>
> Once I write a test for it I'll commit it.
>
> Given that it changes the XML output, I probably wouldn't backport this to 1.8.x.
Opened issue #4463 for this:
http://subversion.tigris.org/issues/show_bug.cgi?id=4463
Re: "svn log --xml -g" doesn't identify a reverse merge but "svn
log -g" does
Posted by Ben Reser <be...@reser.org>.
On 1/16/14, 12:31 PM, Andrew Reedick wrote:
> I need a sanity check. Is this an oversight that needs to be corrected, or am I missing something?
>
> Problem:
> "svn log -g" will explicitly identify a reverse merge, however, when specifying xml output ("svn log -g --xml") no such identification is made.
Yup looks like an oversight. The nesting already shows that it's a merge and
what revision made the merge. But we don't show the direction of the merge.
I've coded up a trivial change to add a reverse-merge attribute on the logentry
element in this case. e.g.
<logentry revision="13" reverse-merge="true">
Once I write a test for it I'll commit it.
Given that it changes the XML output, I probably wouldn't backport this to 1.8.x.