+1, both of these seem very reasonable to me.
Eric, do you have time to file the bug for the original issue (Ben's
"Second -- " heading below)? If not, that's fine, just let us know so
someone else can file it.
Thanks,
-Karl
Ben Collins-Sussman <sussman@collab.net> writes:
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 9 19:07:35 2002