Re: RFC: svn mergeinfo improvements for 1.5

On Tue, Mar 18, 2008 at 9:33 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> Troy Curtis Jr wrote:
> >> A) When displaying eligible revisions display only those that affect
> >> the merge source (i.e. don't display revisions, which if merged, would
> >> be no-ops).
> >
> > I haven't played with the merge-tracking features in 1.5 too much yet, so it
> > blows my mind that this isn't already true. That would go a long way toward
> > de-cluttering the output for sure!
>
> Actually, it doesn't. This change (which I've implemented, by the way) has
> just as much of a chance of making the output *larger* as it does of making
> it smaller. Why? Because where today it might claim that "r4:10" is
> eligible for merge, taking into account that maybe r8 is a noop means that
> displaying the list of *real* merges now actually expands to "r4:7, r8:10".
>

Good point! Now that you say that I can remember several time when I wish
svnmerge.py would have been smart enough to include the no-op revs in a single
merge operation. There have been times when splitting up the range caused two
separate merge operations which in turn caused needless conflicts. I guess I
just popped off without really thinking about it.

>
>
> >> B) Support only one target, still support --from-source filter.
> >>
> >> C) By default show only merged revisions. Add a new option
> >> --merged-revs ARG ('merged', 'eligible'). Yes, as things stand now,
> >> it would make more sense to just use an option like '--show-eligible',
> >> but we want to be ready for the day when true revision blocking is
> >> available so we can easily see --merged-revs=blocked.
> >>
> >
> > At the risk of bike-shedding a little I do have a suggestion here. Change the
> > '--merged-revs' to something like '--display-revs'. The option
> > '--merged-revs=blocked' and '--merged-revs=eligible' doesn't "read"
> > quite right.
> > But '--display-revs=eligible' immediately says what it is doing: Displaying the
> > eligible revisions.
>
> I think we toyed with the idea of --show-revs or --mergeinfo-kind or
> something, too.
>
>
> > I also think the default should be show eligible ranges since that tends to be
> > the more interesting case. Otherwise I think people will effectively have to
> > type this EVERY innovaction of the mergeinfo subcommand:
> >
> > svn mergeinfo --display-revs=eligible
>
> Well, yes, if you assume that people will use 'svn mergeinfo' mostly to see
> what needs to be merged versus what has already been merged, that's true.
> But I think the jury is out on whether that is reality. (I suspect they
> won't use 'svn mergeinfo' at all if we don't make some of these changes
> which facilitate associated eligible-revs with log messages they can use to
> review those revs.)
>

I think that your parenthetical is right on the money...I rarely look at the
raw list, it just isn't that useful in general because revisions don't really
MEAN anything. In fact, the first script I would write when I seriously started
using 1.5 would be something to parse the merge-info output and give me the
log messages (which would be that much easier with one range per line).

I guess I'm a victim of not being able to effectively see past
my group's use of the svnmerge script for merge-tracking. I basically think
of the mergeinfo tool as a way to get a list of eligible ranges. In fact,
when I first looked at the merge-tracking changes to Subversion, the first
thing I looked for was "How do I see the list of available revisions to
merge?"

Perhaps we should take a poll of all the current users of svnmerge.py and see
what they want to look for most of the time?

>
> >> D) Print the revision lists as one range per line, e.g.:
> >>
> >> >svn mergeinfo \svn\src-branch --merged-revs eligible
> >> Source path: /trunk
> >> Eligible ranges:
> >> r29080:29084
> >> r29089:29090
> >> r29091:29093
> >> r29107:29110
> >> .
> >> <snip>
> >> .
> >> r29869:29877
> >> r29878:29882
> >> r29884:29943
> >>
> >
> > Much more readable, even if you do have to pipe it to a pager to make it
> > useful. :)
>
> Actually, Julian and I were now thinking we should print one revision per
> line. If you think about it, in any decently sized project with many active
> branches, the chances of having contiguous revisions eligible for merge for
> a given source degrades quickly (because commits from various branches are
> all interleaved). So why not pre-emptively do one revision per line, which
> sort of naturally expands to adding a --verbose flag that turns those into
> blocks of 'svn log' output?

I think that is probably true, I'm pretty sure it's true with my projects at
work. However, it just seems wrong, especially if you think of looking at the
'merged' revisions. In my project you'd get 30000-40000 lines right at the
top, instead of:
  r1:50000

  Which might be very distracting. If a large project naturally fragments,
  then let it fragment. In the "worse" case they'll have one rev per
  line...but at least the smaller guys won't have to see the same thing.
>
> --
> C. Michael Pilato <cmpilato_at_collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
>

Troy

-- 
Beware of spyware. If you can, use the Firefox browser. - USA Today
Download now at http://getfirefox.com
Registered Linux User #354814 ( http://counter.li.org/)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org