Daniel Rall wrote:
> Mike, sorry if I'm being dense here, but I don't really follow this
> change. svn_client_suggest_merge_sources() is intended to (when
> possible) automatically select the correct merge source URL for a
> target. Removing its usage means that the user will either have to
> manually enter a URL.
>
> However, your commit log suggests that you've made the merge source
> the same as the target, which makes no sense to me.
The problem with defaulting to the copy-from source is that this case:
svn merge -c -SOME_REV
will try to undo a change made on the copy-from source, not a change made on
the target. But clearly, the user expectation for such an invocation is the
latter.
Secondly, pulling from the copy-from source falls completely over if you are
working on a branch that's been renamed (as is not altogether uncommon).
The only consistent UI that means the same thing every time and gets the
same results regardless of scenario is to let the default source of the
merge be the same as the target.
Karl has suggested on IRC that we treat 'svn merge' (no revision specifiers)
differently from 'svn merge -[cr] ...'; that we let the former mean "go get
all the outstanding changes from my copyfrom-source, and the latter treat
the source as "self" unless otherwise provided at the command-line. That
has a distinct flavor of insconsistency about it, too, though -- folks will
expect that -r/-c will simply pull a subset of what a "full merge" would
provide.
Other options include leaving trunk the way it is, except that if folks add
-g [--with-merge-history] we try to find the best merge source
automatically. It is this option that I endorse.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Fri Nov 30 19:38:52 2007