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?
Please refer to this email thread for more details:
http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=643345
OTOH, when a deleted target contains unmerged modifications, 'mergeinfo'
does not detect it. I can't come across a clear solution for this
problem though. Let me know if this should be tracked in an issue. A
test recipe for this bug is available in this email:
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=136399
Thank you!
--
Regards,
Bhuvaneswaran
Received on 2008-03-26 16:12:12 CET