Is it me, or are we people implementing merging without a lot of design
review on the dev list?
On Thu, 2002-01-17 at 18:17, cmpilato@tigris.org wrote:
> The svn_fs_check_related function compares two node IDs to see if they
> are related, either through revision history, or through copy-from
> history! This is the sanity check we need for 'svn merge' and 'svn
> switch' (as in, "Um...these things you're trying to merge aren't even
> related, so if you really want to do this, please pass --force to the
> command.")
I don't think this is a good idea.
For instance, suppose I'm using "svn import" to bring in vendor versions
of emacs into /emacs/20.1, /emacs/20.2, etc., and I have my own locally
modified version in /emacs/trunk. When I want to update my local mods
from version 20.1 to 20.2, I'll want to do a merge of the changes from
/emacs/20.1 to /emacs/20.2 into /emacs/trunk. At least some of the
pairs won't be related; do I really need to use --force for such a
common scenario? It's bad to teach users to use --force when they're
not doing something really odd, or they'll just use it all the time and
lose all of the safeties.
More philosophically, the "relatedness" check between nodes is suspect
enough when it's only being used as a performance heuristic. Making it
user-visible in ways like this seems like a great way to make Subversion
appear complicated and baroque to users.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:57 2006