On Thu, Mar 27, 2008 at 3:36 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> 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!
>
> 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.
>
> 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. :-(
>
> 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 would be fine with any default, or even just requiring the
--show-revs option always.
> 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.
I am still not sure that use case is real. It sounds good, and like
something you would need, but then when I think of the output it just
never seems useful to me.
> 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?
Somewhere dlr has to be chuckling. We went through all of these
gyrations last summer if you want to check dev@. It was a lot harder
to get people to comment back then. Using svn log never felt right
and you would have to add a lot of new options to the command.
> 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.
As long as the API exists I do not care. Having seen this information
in a GUI I know that it is useful and it would be nice if the CLI
could do it. I think we could reach consensus around svn mergeinfo
and be done with it.
--
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 20:53:47 CET