Eric Gillespie <epg@pretzelnet.org> writes:
> I have been sitting on this problem for months.
I'd like to summarize this thread and make a proposal. I've thought
about it a bit, and had discussions with kfogel and cmpilato.
First -- the behavior of dir_delta. Cmpilato wrote this routine to be
sensitive to ancestry, and now it seems that this causes a whole lot
of unintuitive behavior for users, especially when running 'svn diff'
and 'svn merge'. Philip has correctly pointed out that if users
actually attempted to preserve relationships, svn would behave well
(that's the whole point of svn_load_dirs.pl). However, if a user
ignorantly compares two unrelated trees, the tool should still be
useful. At the moment, svn is punishing people by printing huge
numbers of deletes and adds. svn *should* be able to compare
unrelated trees and show reasonable output.
So I propose an enhancement: give dir_delta a new "mode" which
desensitizes it to ancestry. If it sees two files or dirs have the
same name -- that's enough. It just won't check for relatedness.
If two files have the same name, it will send a patch (instead of
deleting/adding), regardless of relatedness. If two dirs have the
same name, it will recurse into the dirs (instead of adding/deleting),
regardless of relatedness.
Once we've implemented this, it's simply a matter of making the two
modes available to 'svn diff' and 'svn merge'. I don't really care
which behavior is the default; we can add options to toggle
ancestry-sensitivity on or off.
Second -- Eric's original bug. He ran 'svn diff' on two unrelated
file URLs. Consistent with dir_delta, he was shown two complete diffs
representing a delete and an add. In Chicago, we're all three in
agreement that this should never happen. We don't care about how it's
implemented, or whether it "makes sense" given the implementation --
it's just wrong output. None of us could come up with a *single*
use-case where a user would ever want or expect this behavior, even
if they knew svn's internals inside and out. This should be filed
as a bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 9 18:58:15 2002