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!
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.
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
Received on 2008-03-27 20:36:47 CET