On Thu, Mar 27, 2008 at 4:29 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Thu, Mar 27, 2008 at 4:24 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> > On Thu, Mar 27, 2008 at 3:36 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>
> > > C. We still support --from-source. But we apparently have decided to
> > > support *not* providing a source, we still has us trying to deal with
> > > multiple sets of output at once (dividers, indentation, etc.). That reduces
> > > the scriptability of the output's one-rev-per-lineness, because now wrappers
> > > have to pay attention to these section dividers and maintain state. :-(
> >
> > If scriptibility is that important, than how about this (possibly
> > quite crazy) idea:
> >
> > i) If you don't provide a --from-source but there is only *one* from
> > source then svn mergeinfo works. This saves users from typing
> > --from-source all the time, for the 1.5.x branch for example.
> >
> > ii) If you don't provide a --from-source but there are *multiple*
> > sources, then return an error saying there are multiple sources and
> > one must be specified (and suggesting iii).
> >
> > iii) Add --show-sources option which lists all the merge sources (one
> > source per line of course, allowing scripts to run this first then run
> > svn mergeinfo --from-source on each result).
>
> These are pretty good ideas. I was thinking something similar but
> could not get to the point of a suggestion. While I tend to think a
> user will only need to see one output, the one part I was concerned
> about was how can they see a list of what they can look at.
>
> Maybe a bikeshed, but could we possibly do --show-revs=sources ?
That sounds ok, except that maybe the option should simply be --show
[eligible | merged | sources], or maybe --show-info, something besides
--show-revs, since show-revs=sources isn't going to list revisions at
all.
> > > D. We've discussed not showing both eligible and merged [and blocked] at the
> > > same time, but using a switch to say which flavor of output we want. That's
> > > cool, because it reduces our indentation/output-sets count again. But I
> > > disagree with the idea of making "eligible" the default while still
> > > maintaining the subcommand name "mergeinfo" which to me -- admittedly
> > > tainted by knowledge of the internals -- means the command will show you
> > > information about merges, not about would-be merges that may never come to
> > > be. Besides, the claim that "you don't need 'svn mergeinfo' to show actual
> > > merges by default because 'svn pget svn:mergeinfo'" is only true when you
> > > happen to execute 'svn mergeinfo' on the root of a branch which said
> > > svn:mergeinfo property is likely to reside.
> >
> > I'm still partial to showing eligible by default, but only because
> > that is what I'd tend to use it for. But I don't feel that strongly
> > about it either way. I mean honestly, does *anyone* feel that
> > strongly about what the default it? How about whoever codes it gets
> > to choose? ;-)
>
> Personally, I would be OK with --show-revs being mandatory. But I
> think showing the merged information makes some sense just because of
> the command name. dlr and I went through all of this back when we
> were discussing a command name. These sorts of questions essentially
> paralyzed us.
In the interest of reducing paralysis I hereby do a 180 and say +1 for
merged revisions as the default.
Paul
---------------------------------------------------------------------
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 21:38:42 CET