[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: RFC: svn mergeinfo improvements for 1.5

From: Paul Burba <ptburba_at_gmail.com>
Date: Tue, 25 Mar 2008 17:10:56 -0400

On Tue, Mar 25, 2008 at 11:59 AM, Karl Fogel <kfogel_at_red-bean.com> 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.

I was suggesting --show-revs ARG (eligible | merged) for two reasons.
First, because we might have "true blocking" one of these days and
adding 'blocked' as a valid arg seemed better than later adding yet
another option, --show-blocked. The second reason is that I don't
want to show both merged and eligible revisions in one pass since that
makes the log indentation problem that much worse.

> > 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*.

Ok, you've sold me with that last point. +1 to one revision per line
(or is that one line per 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.

Hmm, yeah, that is a bit confusing. I just wanted a way to make the
"log" output of svn mergeinfo analogous to svn log's, i.e.:

  svn log -q ---> Rev/Author/Date
  svn log ---> Rev/Author/Date and Log Message
  svn log -q -v ---> Rev/Author/Date and Changed Paths
  svn log -v ---> Rev/Author/Date, Log Message, and Changed Paths

> 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.)

IIUYC, you suggesting this:

  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
  svn mergeinfo -v --> No log info
  svn mergeinfo -q --> No log info

If that is what you are saying then +1.

Paul

> -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 22:11:25 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.