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 ?
> > 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.
--
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 21:30:04 CET