On Thu, Mar 27, 2008 at 3:36 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>
> Mark Phippard wrote:
> > On Thu, Mar 27, 2008 at 2:21 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> >> Now, note that if we output revision ranges in 1.5.0, we can always
> >> switch to individual revision numbers in 1.5.1 or later, since the
> >> latter is a subset of the former anyway (unless we consider ourselves to
> >> have promised to always use ranges where possible, but I don't think we
> >> have promised that).
> >>
> >> But it would be nice to offer just one, canonical output format from the
> >> start. As you can tell, I think individual revs are much more useable.
> >> Has anyone got an objection?
> >
> > I thought we had just agreed on that. I was also suggesting my log
> > idea would also cover this. As it would be one revision per line, it
> > would just contain some additional information on each.
>
> Okay, let me try to flush my brainstate on this issue.
>
> A. Only accept a single TARGET. Everybody seems cool with this. This
> reduces indentation by one level compared to where we are today. Yay!
+1
> B. Always show log-style output, honoring both the -q and -v flags as they
> apply to 'svn log'. This gives us one revision per line (plus some other
> revision metadata) in -q case, and really useful full data in the -v case,
> plus that in-between gunk in the -qv case. This forces the output into the
> realm of needing section dividers, unless we support indentation of the log
> output. I like this.
+1
> 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).
> 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? ;-)
> If our goal is something that is machine parseable, then the easiest thing
> for scripts to parse would be:
> single-target, single-source, single-flavor, one-rev-per-line
>
> Anything more adds complications, some more easy to deal with than others.
> So what can we add that brings value to the user without crossing the line
> of machine parseability.
>
> Moving to log output, we have:
> single-target, single-source, single-flavor, one-block-of-lines-per-rev
>
> That's not so bad. But it still leaves us unable to ask, "What merges have
> been performed to TARGET from any sources?" The minute we allow multiple
> sources, the machine parseability takes a hit, and we're doing indentation
> and section headers.
>
> Since most (if not all) of the problems noted in this thread are UI related,
> not API related...:
>
> 1. Should we ditch the 'svn mergeinfo' command and roll this behavior
> into 'svn log', where we don't have to deal with
> questions of default behaviors because those are already defined?
>
> 2. Should we ditch the 'svn mergeinfo' command for 1.5, and just ship
> the APIs so that TortoiseSVN, Subclipse, and other not-constrained-
> to-text-output consumers can still do their thing?
>
> 2b. Should we provide a bindings script that implements this behavior
> so 1.5 adopters can get the info, but such that we aren't stuck
> maintaining the chosen UI?
>
> Quite honestly, option 2b is looking pretty great to me right now.
>
> --
>
>
> C. Michael Pilato <cmpilato_at_collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
---------------------------------------------------------------------
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:25:05 CET