R – How to update all svn:externals references after a server migration

I believe part of the problem is that the release cycles for the shared components don't necessarily match the release cycles for the projects.

Shared components as described here have their own release cycle. In other words each one could be managed as a separate project (or perhaps the collection of them managed as a separate project) with a release/version number all its own.

Note that the svn:externals definition can include a specific revision.

This allows each of the projects that makes use of a shared component to be developed against a specific release/revision of that shared component (or the collection of shared components), providing a stable set of dependencies for the project. Changes to the components won't break the projects because each project is looking at a specific revision of the components that isn't necessarily the HEAD on the trunk.

While this may seem like more work up front, I believe in the long run this practice provides a better change management process for this type of situation.

Here are some sections about it in the svnbook / TortoiseSVN manual:

This is the svnbook page on svn:externals. It is the most useful resource on the subject.

This one explains four ways to include sub-projects in the workflow (and in the process misses a fifth one: symlinks).

And this last one is a TortoiseSVN-specific page on how to import stuff in a repository (not directly related to svn:externals).