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
Paul
> 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
>
---------------------------------------------------------------------
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:43:25 CET