On Thu, 2005-10-13 at 11:04 +0100, Malcolm Rowe wrote:
> Is svn diff primarily intended to be something that produces classical
> GNU diff unified diffs that can be fed to patch, or is it intended
> to be a tool that works similarly to GNU diff, but that has differing
> [default] behaviour in cases where we think those changes would help
> the user understand the changes better?
I'd say the latter, by default. In the particular common case where you
have modified files but not reorganized the tree, "svn diff" output can
be fed to patch, and that's a good thing, but outside of that case I
don't think we can really achieve that goal in a meaningful way.
For example, suppose I do a really simple tree change: adding a file
without history. "svn diff" produces a diff which will, when fed to
patch, create the file, but patch will of course not "svn add" the file.
So a developer who receives such a diff and applies it in an svn working
copy will have to go to extra work to reflect the tree change. That's
probably the most common use case of applying the result of "svn diff"
using patch.
At any rate, we've applied the latter philosophy up until now, and
people have come to rely on it, so I don't think we can reasonably
change the default behavior to reflect the former philosophy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 13 19:52:33 2005