[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Auto-selection of merge source URL

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2007-11-30 19:38:40 CET

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

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

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.