Question

My situation: I have several components, which sometimes have changes to them, and are shared across a lot of different projects. Each project puts these in a subfolder called /depends. The depends holds a bunch of svn externals for all of our common components.

svn:externals is causing me a lot of time and pain.

• Show log on the project root folder will not show changes for svn:external folders (yet funny enough commit and update will work with svn:externals)
• When you branch, the svn:externals are not branched.
• Because of no branching on svn:externals, any change usually breaks the trunk.
• Tags do not freeze their externals. This really defeats the purpose of tagging.

Remember that I have several projects (Let’s say 10 for this discussion each using the same externals), so keeping normal committed directories for each project would cost me a lot of merging time.

Is there a better alternative for my situation?

Answer 1

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.