"Paul Burba" <ptburba_at_gmail.com> writes:
> 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.
Yay on (A), (B), and (C). See below about (D) :-).
Regarding (C): suggest '--merged' and '--eligible' as the flag names, or
'--show-merged' and '--show-eligible'. Kind of green.bikeshed.com, I
know; maybe it doesn't make much difference. Agree about the default.
> 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...
So what happened to Mike's proposal of one rev per line?
In practice, people are going to be piping through a pager or
redirecting to a file, no matter what. Even with range compression,
these lists only get bigger.
So let's just think about it from a use case point of view. What are
people trying to do? They're probably trying to figure out if a given
revision has been merged and/or is eligible to be merged. The most
useful thing would be if they could search the output *for that exact
revision*.
Also, if you do one rev per line, then filtering out no-op revisions
really is guaranteed to shorten the output. Where as with ranges, then
filtering out no-op revisions can increase the number of ranges, as Mike
pointed out. Although the number of ranges will never be more than the
number of revisions, of course, there is an inherent inconvenience in
dealing with larger numbers of ranges -- if you're searching by eye to
figure out what happened to a particular revision, that is.
> 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?
It sounds like (E) means that adding the -q flag to 'mergeinfo' would
actually cause it to give *more* output, since behaving like 'log -q'
means giving more information than just a revision number.
That's going to be confusing. Instead, how about a --show-log flag or
something, if people want the log messages on the spot? (And then -q/-v
can be meaningful when --show-log is given. They don't have to be
meaningful without --show-log; or we can just save them to mean
something by themselves in the future.)
-Karl
---------------------------------------------------------------------
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-25 17:00:03 CET