On 6/25/07, C. Michael Pilato <cmpilato@collab.net> wrote:
> 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.
The essential question in my view is: Is the ability to edit a patch
before applying it with "svn patch" valuable?
In my opinion, not particularly so; I think the choice between patches
you can edit but can only apply with "patch" (and lose everything but
text changes) and patches you can only edit after you apply them (but
keeps metadata) is perfectly reasonable. However, one of the last
times this was brought up, several people did state that the ability
to edit a patch in a text editor before applying it was incredibly
important and should not be prevented.
--dave
--
David Glasser | glasser_at_mit.edu | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 25 18:42:09 2007