Best way to replace a whole directory tree in Subv

Question

Within my Subversion project I have a few directories that contain other open source projects that my code needs. For example ffmpeg, freetype, matrixssl and a few others.

What is the best way to update SVN to hold the the latest version of one of these projects?

Essentially I will be doing the following (using ffmpeg as an example):

1) Rename current ffmpeg folder to ffmpeg.old
2) Download new version of ffmpeg from net
3) Make sure it and my code compile and work fine together
4) Update subversion to now hold the "new" version of ffmpeg
5) Delete ffmpeg.old directory tree

Answer 1

You can take a look to svnbook talking about vendor branches. This is exactly what you try to accomplish

You can use svn_load_dirs.pl to replace your manual steps 1-5. svn_load_dirs.pl will also keep track of new, moved or deleted files.

Answer 2

I think you've got two options.

A)

1. SVN Delete all the files.
2. Get current & make it work.
3. SVN Add all the files.

Pro: Will make sure no extra files are kept if they are not present in the latest version.

Con: May be time consuming.

B)

1. Download and install the new version over the old one.
2. Make it work.
3. SVN add any new files.

Pro: You can see what has changed in the files of the tool.

Con: May end up with clutter. Depending upon the tool overwriting may cause bugs.

Answer 3

I've got the same situation with CMake, where I keep the binary win32 release checked into our vendor directory:

branches/
trunk/
vendor/
    cmake/
        cmake-2.6.0/
        cmake-2.6.1/
        cmake-2.6.2/
        ...

I then use svn:externals to refer to the CMake version I'm using. Makes it really easy to test upgrading to new versions, and it is also clear which version of CMake I'm using.

Answer 4

If some of the vendor projects also use Subversion, You can add the svn:externals property to the parent directory of Your branch/trunk.

Take a look at the SVN book for more details.

Answer 5

All is correct except that you don't need steps 1 and 5 - if step 3 fails revert changes using svn revert functionality.