Eric Gillespie wrote:
> "Garrett Rooney" <rooneg@electricjellyfish.net> writes:
>
>> Umm, I hate to say it, but that's hideous. Shoving a huge amount of
>> crap that people don't need to see in the default output of svn diff
>> is absurd. Stick this sort of stuff in optional sections that are
>> skipped by default or something, or at least find a way to make it
>> look somewhat human readable. Just because we have a format doesn't
>> mean it's suitable for all uses, and the svn protocol is absolutely
>> not suitable for output in between unified diff sections in the
>> default output of svn diff.
>
> Well, we could stick most of it at the end, with only the
> textdelta bits around the diffs. Or we could invent a new format
> entirely (and still put the editor drive at the end); that's not
> difficult. But i don't think only generating this information
> with an option is the right way to go; people will forget the
> option all the time. It's good to avoid choices where possible ;->.
I may be the lone voice for this particular opinion, but I'm having trouble
seeing why we are trying so incredibly hard to solve two different problems
with one feature.
Yes, I agree -- if we carry on in the way that's been proposed time and time
again, people *will* forget to use the correct option. But why? I think
it's because we're trying so hard to make the output of a
property-and-binary-file-and-tree-delta-preserving diff function look as
close to a property-and-binary-file-change-and-tree-delta-dropping diff
output as possible. Has it occurred to anyone that if 'svn diff --deltas'
(or whatever) generated output that wasn't human-readable *at all*, the
likelihood of accidentally generating the wrong kind of output would be
vastly dimished? So what if folks have to run 'svn diff' twice to provide
both types of output they might need to solve both types of general
change-trading problem? It's *two problems*!
We've discussed this issue to death and have gotten nowhere. *Anything*
that solves the problems, even at the cost of making users perform more than
one step (*the horror!*) is better than the status quo, in which the users
can't do what they want even in a hundred steps.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Mon Jun 25 17:25:18 2007