external library update in a SVN repository

Question

In my repository, I store several external libraries. When a new version of a library is available, I do the following tasks to update it in my repository:

1. checkout my old version of the library
2. recursively remove everything but .svn directories
3. copy the new version of the library
4. svn status to see the changes
5. add new files and directories, delete removed files and directories
6. commit

Is there a better (or simpler) way to achieve this task ?

Note that I cannot use svn:externals because only a few of the libraries I use provide a SVN access.

Answer 1

I think svn externals are what you are looking for. Some good documentation can be found here: http://svnbook.red-bean.com/en/1.0/ch07s03.html

Answer 2

You could create a new repository for each library. Then, when a new version arrives, just copy it into the trunk of the library repository and you should see the modifications and new files identified by SVN - there's no need to remove the old files first. Deleted files are another matter - but I would hope your libraries aren't losing files like crazy so you can probably manage this by hand.

Then, once all your changes are checked in you can tag the trunk as the updated version (probably to match the version of the library) and include that tag as an external to the consuming project.

Answer 3

You can delete whole directory in svn and add it again with new version (assuming a library is in its own directory and not mixed in with other libs). You don't need manufactured history for third party library anyway.

Answer 4

I do something similar, I copy a source tree into a repo I have set up for tracking it locally.

When a new version is available:

• I fetch the library files directly ontop of my WC.
• I view an changes (using tortoise - its easy to see which have changed, the overlays change)
• I commit all the changes.

Its that simple. Obviously you don't get full change history as you're only tracking the 1 version at a time, committing the latest changes, but otherwise its very effective.

Answer 5

What you're doing is actually the cleanest way to manage a vendor branch, especially if you have your own customizations to the code.

In many cases it may not be really needed to track deleted files of the external lib, but OTOH it's easily scripted, so I would keep using this procedure. I do it the same way, in any case.