svn log --xml -g doesn't identify a reverse merge but svn log -g does

2014-01-16 Thread Andrew Reedick
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
authorandrew/author
date2014-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
msgsvn merge -c -15 ./msg
== logentry revision=13
authorandrew/author
date2014-01-16T19:37:17.531316Z/date
paths
path
   text-mods=true
   kind=file
   action=M
   prop-mods=false/branches/test/a.txt/path
/paths
msgbranch 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

2014-01-16 Thread Ben Reser
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.


Re: svn log --xml -g doesn't identify a reverse merge but svn log -g does

2014-01-16 Thread Ben Reser
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

2014-01-16 Thread Ben Reser
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.