On Wed, May 10, 2006 at 06:03:25AM -0500, Ben Collins-Sussman wrote:
> On 5/10/06, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:
>
> >Unless there are two radically different use cases that I've been missing,
>
> Yes, the two radically different use-cases for dealing with a file
> that is schedule-add-with-history are
>
> * "Show me exactly what's going to be sent into the repository."
[which we do for repos->wc diffs]
>
> * "Show me my local edits."
[which we do for wc->wc diffs]
>
> They are mutually exclusive behaviors, but both are legitimate things
> you may want to do with a schedule-add-with-history file. One
> behavior should be the default, and the other should be toggled by a
> switch. At the moment, the 2nd behavior is all we do.
>
Unless I'm misunderstanding what you're suggesting with the first item,
we do both. Diffing a 'renamed' file (actually one deleted and one
schedule-add file) will show a complete deletion of OLD plus:
repos->repos diff, repos->BASE diff, 'svnlook diff': a complete add of NEW
wc->wc diff, 'svnlook diff --diff-copy-from': a diff of NEW against OLD
My argument is that 'svn diff' should be doing one or the other by
default, not changing whether we take account of copyfrom information
based on whether we're doing a wc->wc diff or a repos->wc diff.
> You make a good argument that the 1st behavior should be the default,
> for the sake of consistency with other diff commands. If it's
> changed, please at least make the 2nd behavior still triggerable
> somehow.
>
In an ideal world, I think that, for consistency with GNU diff and
svnlook, and for minimal suprise, 'svn diff' should not take account
of copyfrom information unless a '--diff-copy-from' flag is passed.
We could then extend repos->repos and repos->BASE diffs to accept this
flag as well.
I don't expect this to be entirely uncontroversial, but our current diff
implementation is far from self-consistent - so we're going to have to
break something however we try to fix it (that, or codify our existing
implementation as our ideal design).
Also note that I'm not suggesting any particular behaviour for 'svn diff'
in the face of true renames - that's not something I've spent much time
thinking about yet.
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 12 09:28:46 2006