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".
>> 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.)
>> 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?
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-03-19 03:33:15 CET