Thanks for the reply. I haven't tried your recommended
--ignore-ancestry suggestion. I will give that a spin. For now, I
found the following approach to work:
1) Determine what the release branch or tag you will be upgrading to and
export a copy:
svn export file:///htc/svn/ignitionweb_base/tags/RELEASE_3_3_2_BUILD_3
2) Now to import it into the client repository:
svn_load_dirs file:///htc/svn/3macs/ -t branches/release_3_3_2_build_3
3) You know need to have a current up-to-date client svn sandbox:
svn co file:///htc/svn/3macs/trunk 3macs
4) We now will merge the differences between branches/htc before and
after the merge of release_3_3_2_build_3 into the current trunk. Before
doing so, you need the revision number of branches/htc before the merge.
svn merge file:///htc/svn/3macs/branches/htc_at_216
What are your thoughts on this approach? I have to admit that
svn_load_dirs is voodoo to me at this point!
Joshua Varner wrote:
>On 9/27/05, Michael Caplan <email@example.com> wrote:
>>4) Merge changes:
>> svn merge file:///htc/svn/3macs/branch/test
>This is trying to take branch/test and generate the changes to
>make it match trunk, you want the URLS the other way.
>Since this is an import on the branch, you may also need
>to use --ignore-ancestry. Subversion thinks the new files on
>the branch are unrelated to the ones from the trunk so it may
>be deleting those and adding with history the ones from the
>>All the files common between repository 1 and the client repository get
>>marked for deletion? How should I be approaching this problem?
>The above will work for now. You might want to put everything
>into one repos, since branches are easier to manage that way.
>Merging wasn't intended to work across repositories, it just
>currently does, so this behavior may or may not continue to be
>supported (or may require a --force option).
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Sep 28 16:46:25 2005