Subversion merging changes from a different repository

Question

Hi, I'm really confused. I want to do something that a) seems like it should be pretty simple, and b) other people must do all the time, but I cant find out the best way to do it anywhere.

There's an external repository that contains some 3rd party code. I want to take a copy of version 1 of the code and put it in my own repository, and then customise it for my own needs. When version 2 of that code is released I want to be able to upgrade my customised version with all of the version 2 changes, retaining my customisations.

I've read about vendor branches (http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html) but I don't understand why merging the previous copy of the vendor code and the new copy of the vendor code needs to be so complicated (ie. svn_load_dirs.pl). Surely, if the 3rd party code is stored in an SVN repository, all of the history regarding which files have moved/been deleted is known, so why do you need to tell it what's changed manually?

Quote:

For example, you will have the opportunity to tell the script that you know that the file math.c in version 1.0 of libcomplex was renamed to arithmetic.c in libcomplex 1.1.

I've also read (http://svn.haxx.se/users/archive-2006-04/0285.shtml) that it is possible to simply run a merge between different repositories, but I didn't think that was possible, and whenever I've tried it it's failed (though I could have been doing something wrong).

Can anyone clarify this for me, and suggest the best solution?

Thanks, Jack

Answer 1

I've just tried a brief experiment with TortoiseSVN:

Creating the test repositories

1. create two new repositories in rep1 and rep2
2. check out rep1 into co1
3. add a text file to co1 and check it in
4. export rep1 to ex1
5. import ex1 into rep2

At this stage you will be in the state of having created your local 'branch' in a new repository. The last two steps are all you need for an existing project.

To simulate some changes to the original repo, modify the text file in co1 and commit the changes.

Merging Changes

Now, to create your own working copy, check out rep2 into co2.

We should be ready to try merging from rep1 into co2.

Open the merge dialog for co2 and point it at rep1.

For the 'from' revision select the revision at which you exported your copy (in this case revision 1), or the revision that you last updated your local copy to.

For the 'to' revision select the HEAD or the latest update you want to apply.

Results

This seems to work as expected, with the modifications from rep1 being applied to the working copy of rep2 in co2. These then need to be committed back to your local repository.

Answer 2

I haven't tried this with an multiple repos myself, but I don't see why you can't use the suggestions from of your 2nd link.

svn merge ORIGINAL@REV UPGRADE@REV LOCAL_PATH

This effectively tells SVN to take all the changes between the original checkout and the version you want, and to apply them to your local copy.

Protip: I always use explicit revisions and include the merge command with the commit message, so that I can easily review the history and understand how to reproduce or undo changes.

Answer 3

The vendor branches link you provided does effectively describe the process of what you want to do. It is a perfect solution relative to allowing you to do a straight update (import) of the vendor branch, and then as you allude to, will then allow you to merge the vendor's updates in with your changes in the main development branch.

The problem is that Subversion really doesn't provide direct support for file renames and moves of files between directories for the successive update from the vendor code because you are just getting snapshots of the source files' content....something needs to run the commands into the version system to indicate what changes are being made to the tree of file names that make up the new version. This is the purpose of the svn_load_dirs.pl script process. It helps you to get your version history manipulated around to match up the branches so that you can then proceed with the merge. If the vendor didn't rename and/or move files around between versions you imported, you would not have this problem.

In any case, the process described there is what you/need to do.