On Thu, Mar 27, 2008 at 11:41 AM, Paul Burba <ptburba_at_gmail.com> wrote:
>
> On Wed, Mar 26, 2008 at 11:11 AM, Bhuvaneswaran Arumugam
> <bhuvan_at_collab.net> wrote:
> >
> > On Tue, 2008-03-25 at 11:59 -0400, Karl Fogel wrote:
> > > "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.)
> >
> > While we're talking about adding a '-q' switch for 'mergeinfo', let me
> > put a new request. Right now, if 'mergeinfo' is run against a deleted
> > target, we print:
> > Eligible revisions: (source no longer available in HEAD)
> >
> > Users find it convenient to provide a switch to suppress merged/eligible
> > revisions for a deleted target. How does it sound to suppress it if '-q'
> > switch is passed?
>
> I guess it makes more sense to use -q for that rather than having its
> meaning dependent on the presence of --show-log. That leaves us with
> the problem of how to get the different log formats when using svn
> mergeinfo. How about just using four long options to correspond to
> the four log formats?
>
> svn mergeinfo --> NO LOGS
>
> svn mergeinfo --show-log-q --> svn log -q
> svn mergeinfo --show-log --> svn log
> svn mergeinfo --show-log-q-v --> svn log -q -v
> svn mergeinfo --show-log-v --> svn log -v
Why not just always make the output follow log?
svn mergeinfo
svn mergeinfo -q
svn mergeinfo -v
svn mergeinfo -q -v
If you just want one revision per line, you can use svn mergeinfo -q
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
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-27 16:51:03 CET