Help me understand Svn merge

Question

I don't understand svn merge. Here's the scenario:

We have a branch that contains the latest stable copy of our code. I will refer to this branch as 'the branch'. There's also a trunk branch which contains a few new additions, but we don't want to mess with that at this point.

We have a vendor branch which contains an updated version of the library on which our app runs. I want to merge the new changes in this vendor branch with 'the branch' so that we get updates to the library without me having to go through, file by file, and figure out what is new. No Thanks.

Now, I realize this is probably simple, but I have tried a lot of stuff, and read a lot of tutorials, but I am still unable to wrap my head around what, exactly, I should be merging with what.

For the record, I am using Tortoise.

EDIT: This is a clarification, but our app runs the library at the root level. I don't know if it matters. So 'the branch' is basically the same as 'vendor', but with our changes.

Answer 1

Something like this should do it for you. Subversion understands standard diff and diff3 pretty well, but it doesn't always play nice with 3rd party (graphical) diff utilities.

$ cd "the branch"
$ svn merge --diff3-cmd=diff3 svn+ssh://yourrepository/path/to/vendor_branch"

Answer 2

Vendor branches are a technique that allows you to maintain your own patches against an external code base, while keeping the ability to absorb new releases ("vendor drops"). This involves merging of your own changes and the vendor changes. I wouldn't recommend trying such a thing as your first experiment with merging, because it is an advanced and complex use case.

However, it sounds like you are not modifying the third-party code at all. Upgrading to a newer version of the third-party code therefore shouldn't involve merging.

The trick is to keep your own code and the third-party code separate (they are separate projects) and bring them together with svn:externals. Example repository layout:

/externallib/1.0
/externallib/2.0
/project/trunk
/project/trunk/externallib

The /project/trunk/externallib folder doesn't really exist in the repository, but appears in your working copy because of svn:externals property on the trunk folder with this value:

^/externallib/1.0 externallib 

Upgrading the trunk to version 2.0 of the external library is then a matter of changing svn:externals definition to this:

^/externallib/2.0 externallib 

Note that you should treat the externallib releases as tags; if you start modifying them you will influence the content of /project/trunk/externallib without any explicit commits in /project/trunk, which is a bad thing.