views:

2817

answers:

5

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
+1  A: 

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

Dandikas
Will this handle deleting files that are no longer used in the new version or will I have to detect and delete them manually?
KPexEA
use svn delete to delete old tree before downloading latest version. Then there is no need to resolve anything, and if step 3 fails - revert. Nothing gets really deleted from SVN anyway.
Dandikas
svn_load_dirs.pl will take care of the deleted files
DanJ
A: 

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.

Tilendor
What is step 1 used for in both scenarios? Sounds to me as an old habit from days when you did not use SVN.
Dandikas
fixed that. I was going off of the question too much
Tilendor
+1  A: 

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.

JesperE
so essentially the svn project contains all the versions and you just alias to the current one?
KPexEA
Yes. There is no point of removing the old ones, since the vendor directory is never directly checked out; it is only referred to using svn:externals.
JesperE
+5  A: 

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.

Peter Parker
A: 

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.

Black
True, but this leaves you at the mercy of the vendor's repository. See answer http://stackoverflow.com/questions/192915/best-way-to-replace-a-whole-directory-tree-in-subversion/192965#192965 which describes vendor branches, for a more controlled method.
Martijn Heemels