On Tue, Mar 18, 2008 at 10:52 PM, Troy Curtis Jr <troycurtisjr_at_gmail.com> wrote:
> 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
Ok, taking into account what has been said so far (including some
off-dev conversations between Mike, Julian, and myself), how does the
revised proposal sound?
A) When displaying eligible *or* merged revisions, display only those
that affect the merge source (i.e. don't display revisions, which
if/when merged, would be/were no-ops). There has been some discussion
that displaying the no-op merges might also be useful on occasion, but
I still feel that filtering the no-ops is more useful, more of the
time. If, after 1.5 releases, people are clamoring for the no-ops, we
could add a --show-no-ops option. Heck, we could do this now if
people really think there is a need.
B) Support only one target, still support --from-source filter.
C) By default show only eligible revisions. Add a new option
--show-revs ARG ('merged', 'eligible'). After more thought I like
'eligible' as the default better, since the merged revisions are
already represented in the svn:mergeinfo prop.
D) Print the revision lists as one range per line (if -v is not
specified). This keeps things easy to read/parse, while attempting to
avoid the excessive vertical output one rev per range more or less
guarantees. Before you say no read E...
E) Add support for the --verbose/-v and --quiet/-q flags. If
specified, this produces output exactly as if doing svn log -q/-v for
each of the eligible/merged revisions. If the --from-source option is
specified then we don't need to indent, but if not we'll need to
indent the log output per source. The latter is going to be a bit
ugly, but I see no way of avoiding it.
Thoughts?
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-03-24 21:04:01 CET