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