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

Re: Merge problems on large repository with many copies

From: Sam Minnée <sam_at_silverstripe.com>
Date: Fri, 10 Oct 2008 10:54:16 +1300

Hi everyone,

Is anyone able to shed some light on how I might debug this? In its
current state, subversion merging is pretty much unusable for us.

Is there any way of getting more verbose error information out of
Should I raise this as a bug?


On 8/10/2008, at 2:29 PM, Sam Minnée wrote:

> Hi all,
> I'm having some problems with merge tracking in subversion 1.5.
> http://svn.silverstripe.com/open/modules/sapphire/branches/
> nestedurls has been copied from http://svn.silverstripe.com/open/modules/sapphire/trunk
> We then try and merge changes from trunk into the feature branch:
> svn co http://svn.silverstripe.com/open/modules/sapphire/branches/nestedurls
> cd nestedurls
> svn merge http://svn.silverstripe.com/open/modules/sapphire/trunk
> But we get this error:
> Working copy path 'core' does not exist in repository
> The "core" directory in question is probably http://svn.silverstripe.com/open/modules/sapphire/trunk/core
> .
> We are running svn 1.5.2 on the client and 1.5.1 on the server
> (waiting for debian sid to release 1.5.2!) but that said, I have had
> similar issues with a duplicate of this repository running 1.5.2 on
> the server.
> Our repository is several years and more than 60,000 changesets old,
> and I think we've hit an edge-case that hasn't yet been dealt with
> in 1.5. One of the main quirks of our repository is that we have on
> a lot of quite deep svn cp commands:
> We first created /modules/sapphire/trunk
> Then copied it to /modules/sapphire/branches/2.0
> Then copied to /open/modules/sapphire/trunk
> Having your trunk based on a chain of copies appears to confuse
> subversion quite a bit. To further complicate matters, the access
> rights of /modules/ are different from /open/. All of these copies
> were part of an effort to open a previously closed-source project.
> In retrospect, I think that I might have approached the migration a
> little differently, but without deleting all of my change history,
> I'm stuck with the repository as-is.
> What I am hoping is that I have found a bug that would be able to
> fixed in an upcoming subversion release. To this end, I am more
> than happy to collaborate with the developers in getting this
> resovled.
> All of the svn URLs mentioned are publicly readable, but if anyone
> is willing to help diagnose this problem and needs more access,
> please email me on sam at silverstripe dot com.
> As an alternative solution, if anyone knows of a tool to
> "rationalise" the subversion history and get it all flattened out
> onto 1 trunk (instead of the 3 directories linked by copies that we
> currently have), I would be very interested!
> Thanks,
> Sam Minnee
> SilverStripe

To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-10-09 23:54:37 CEST

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.