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

Re: merge fails - svn: URL xxx/xxx doesn't match existing url xxx/yyy

From: Jeb <jeb.beasley_at_penske.com>
Date: 2006-05-10 13:01:35 CEST

Excellent - Yes, I would say that the two branches do not share ancestry
in the eyes of Subversion. The copies diverged long ago between local
and offshore developers. Local developers created one branch. Offshore
developers created the other. In the past, code was synchronised from
CVS used by offshore into a local source safe repository manually for
deployment, now both sets of code are in Subversion.

Using the --ignore-ancestry flag did the trick. I will try to see if
that helps the other scenario where we get the "Obstructed Update" "Revison
320 doesn't match existing revision 319"

Jeb Beasley

Garrett Rooney wrote:

> On 5/9/06, Jeb <jeb.beasley@penske.com> wrote:
>> I did the following from the command line
>> svn co http://.....branches/offshore/JavaSource c:\proj\da\JavaSource
>> cd c:\proj\da\JavaSource
>> svn sw http://....branches/dev_gh/JavaSource
>> svn merge http://....branches/dev_gh/JavaSource
>> http://....branches/offshore/JavaSource
>> Then I get the following
>> D com_penske_delegatedadmin_actions.dnx
>> A com_penske_delegatedadmin_actions.dnx
>> D conf\delegatedadmin.properties
>> D conf\ApplicationResources.properties
>> D conf\deladminlinks.properties
>> D conf\log4j.properties
>> D conf
>> Stopped with error
>> svn: URL
>> 'http://svn.penske.com/svn/webprojects/admin/delegatedadmin/branches/of
>> fshore/delegatedadmin/JavaSource/conf' doesn't match existing URL
>> 'http://svn.pe
>> nske.com/svn/webprojects/admin/delegatedadmin/branches/dev_gh/delegatedadmin/Jav
>> aSource/conf' in 'conf'
>> echo %errorlevel%
>> errorlevel 9009
>> Files should not be deleted, the exist in both branches.
>> thanks for any help you can provide
> Do the files in question actually share history? For example, if you
> created both of those branches by copying from a commen ancestor, and
> the file existed in that common ancestor, and it wasn't deleted and
> then added or something like that in one of the branches, then you'd
> expect your merge to leave it alone, but if the versions on the two
> branches are totally unrelated, then removing the existing copy and
> adding a new one is the correct behavior. See the --ignore-ancestry
> option to merge for a way to avoid this behavior.
> -garrett

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 10 13:03:02 2006

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.