[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: augmented diff design patch format

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2007-06-25 19:16:56 CEST

On 6/25/07, C. Michael Pilato <cmpilato@collab.net> wrote:
> 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.

Exactly my sentiments when I tried raising the issue on IRC yesterday
night! Thank you for putting it so clearly.



To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 25 19:16:37 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.