[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Question about svn log -g

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: 2007-10-14 04:54:56 CEST

Troy Curtis Jr wrote:
> On 10/13/07, Hyrum K. Wright <hyrum_wright@mail.utexas.edu> wrote:
>> Troy Curtis Jr wrote:
>>> Last night I checked out the latest trunk (r27167) to start really
>>> looking at the new merge-tracking features (which I am really excited
>>> about). I'm a little confused at the choice of working in the 'svn
>>> log -g' output. (I'm using the merge-tracking early adopter sample
>>> repo).
>>>
>>> Here a snippet of the log output in question: (svn log -gv
>>> file:///share/repo/trunk)
>>>
>>> <log>
>>> ------------------------------------------------------------------------
>>> r8 | merger | 2007-05-30 14:29:16 -0500 (Wed, 30 May 2007) | 1 line
>>> Changed paths:
>>> M /trunk
>>>
>>> Block r7 from branch a
>>> ------------------------------------------------------------------------
>>> r7 | auser | 2007-05-30 14:27:04 -0500 (Wed, 30 May 2007) | 1 line
>>> Changed paths:
>>> A /branches/a/blocked
>>> A /branches/a/blocked/index.html
>>> Result of a merge from: r8
>>>
>>> Create blocked folder. This should only ever exist on branch a
>>> ------------------------------------------------------------------------
>>> r6 | merger | 2007-05-25 19:16:28 -0500 (Fri, 25 May 2007) | 1 line
>>> Changed paths:
>>> M /trunk
>>> M /trunk/index.html
>>> M /trunk/news/index.html
>>> A /trunk/products/medium.html (from /branches/a/products/medium.html:5)
>>>
>>> Merge branch a. Added medium product.
>>> ------------------------------------------------------------------------
>>> r4 | auser | 2007-05-25 19:13:35 -0500 (Fri, 25 May 2007) | 1 line
>>> Changed paths:
>>> M /branches/a/index.html
>>> M /branches/a/news/index.html
>>> A /branches/a/products/medium.html
>>> Result of a merge from: r6
>>>
>>> Create page for medium product.
>>> ------------------------------------------------------------------------
>>> </log>
>>>
>>> "Result of a merge from: r8" in the log for r7 for example doesn't
>>> make any sense to me. What this to me is "r7 is the result of a merge
>>> from r8", which of course doesn't make since. How can a revision be a
>>> merge result FROM a later revision? I really think it should really
>>> be "Source of a merge for: r8".
>> There was some discussion a while back about changing the wording, but I
>> don't know if that ended up going anywhere. One of the proposed
>> wordings was "Via merge in: rXX" Would that be less confusing?
>>
>>> I'm looking at this as how I'm going to explain it to my users when we
>>> switch (hopefully some time next summer after 1.5 has been out for a
>>> while).
>>>
>>> Hum looking at it just now I think I see what it really means. Your
>>> really saying that the display of r7 is a result of it being the
>>> source of a merge from r8. Even then I still think the
>>> wording/formatting is quite right. Perhaps indenting the logs of the
>>> sources? Otherwise this is very confusing and I KNOW I'll be
>>> fielding many confused questions from my users down the road.
>> This was discussed at length back in April:
>> http://svn.haxx.se/dev/archive-2007-04/0650.shtml
>>
>> The goal of 'log -g' is to show where the changes really happened,
>> regardless of whether it was on a branch or on the main line of
>> development. The conclusion of the above thread was that message
>> indentation didn't really add very much toward accomplishing that goal.
>>
>> -Hyrum
>>
>>
>>
>
> Yes, I think "Via merge in: rXX" would be better. It doesn't seem
> perfect but at least it doesn't imply that it means something else.
> Hum, or maybe "Source of merge in: rXX", or "Merge source for: rXX".
> This way it describes the relationship of the revision the sentence is
> in to the revisions listed and not the relation of the LOG of the
> revision to the LOG of the revisons listed.
>
> One of the things I think indenting would get you is parsability.
> With very simple parsing you would know that rX starting in the first
> column would be a "real" revision for that path and if there was white
> space it would mean it was a source revision. Of course you can still
> dig into the message to find the "Result of merge from: rX" (or
> whatever the final wording is :) ), but that is harding.
>
> I can see the issue of pushing the content too far to the right,
> especially if you did more indention for more depth of merge-tracking.
> But even one or two spaces would really set those "source" revisions
> off from the rest of it and it would be immediately obviously that
> they are "dependent" revisions.
>
> All that said I do really believe the wording should be changed to
> something else. Even though I now understand what you are trying to
> say by it, it still seems to mean something else to me and I really
> have to work to see it your way.

Thanks for the input regarding wording. I'll let the thread sit for a
while so people can comment, but if I don't hear anything, I'll go ahead
and commit the wording change in a couple of days.

If you are looking for parsability, the '--xml' switch does provide the
nesting you want, and it is designed to be a bit more parsable than the
standard output.

-Hyrum

Received on Sun Oct 14 04:54:52 2007

This is an archived mail posted to the Subversion Dev mailing list.