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

Merge that Adds Dir Fails

From: Brian Buesker <bbuesker_at_qualcomm.com>
Date: 2005-02-22 18:42:31 CET

I encountered a case when an svn merge fails although I wouldn't have
expected it to. Basically, the problem can be reproduced with the
repository set up as follows:


If I checkout from the trunk, and then try to merge the changes between
tag1 and branch1 (ie. svn merge $REPOSURL/tags/tag1
$REPOSURL/branches/branch1), I get the following output:

D dir1/dir2
D dir1
subversion/libsvn_wc/adm_files.c:910: (apr_err=155000)
svn: URL 'file:///opt/data/bbuesker/tmp/svn.3128/branches/branch1/dir1'
doesn't match existing URL
'file:///opt/data/bbuesker/tmp/svn.3128/trunk/dir1' in 'dir1'

The first thing I don't understand is why the merge is showing dir1/dir2
and dir1 being deleted. If instead I do a merge just consisting of dir2
(ie. svn merge $REPOSURL/tags/tag1/dir1/dir2
$REPOSURL/branches/branch1/dir1/dir2) from within dir2, the merge
succeeds and dir3 is added.

When I tried the same sequence of steps with the trunk version of SVN, I
don't get the "doesn't match existing URL" failure, although it does
show dir1/dir2 and dir1 being first deleted and then added again. Is
this expected behavior? It seems that it would be confusing to users to
see a directory that they know should not be deleted actually being
deleted and then added again (at least according to the output of svn

I think the problem has something to do with the way the branch and tag
were created (using mkdirs during an import). If instead they are copied
from the trunk, the merge works fine and I don't see anything being
deleted. Unfortunately we rely on using svn mkdir operations in various
steps of our SCM process. So it looks like the workaround for now is to
make sure the merge is done within the directory containing the one
being added.

I have attached a script which can be used to reproduce what I am
observing. The fix in the trunk is acceptable, although it does still
seem to me that the output is a little confusing for users who are not
as aware of what svn is doing.

Here is my environment:
OS: Fedora Core 3

SVN Version:
$ svn --version
svn, version 1.1.2 (r12471)
 compiled Jan 7 2005, 15:34:50

Copyright (C) 2000-2004 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet

The following repository access (RA) modules are available:

* ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
- handles 'http' schema
- handles 'https' schema
* ra_local : Module for accessing a repository on local disk.
- handles 'file' schema
* ra_svn : Module for accessing a repository using the svn network
- handles 'svn' schema

$ gcc --version
gcc (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO

$ perl -v

This is perl, v5.8.5 built for i386-linux-thread-multi

Copyright 1987-2004, Larry Wall

Perl may be copied only under the terms of either the Artistic License
or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'. If you have access to the
Internet, point your browser at http://www.perl.com/, the Perl Home Page.

Berkeley DB Version: 4.2.52

OpenSSL Version:
$ rpm -q openssl

Please let me know if you need any more information.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Received on Tue Feb 22 18:44:54 2005

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

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