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
subversion?
Should I raise this as a bug?
Sam
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