On 10/13/07, Hyrum K. Wright <hyrum_wright@mail.utexas.edu> wrote:
> 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.
Oh, if you're *looking* for bikeshedding :-), then sure: I like Troy's
suggestions better than the current wording. (Or just "Merged in:
r123".)
--dave
--
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 15 19:00:49 2007