I'm working with a small-ish team of developers. We're using Subversion for version control. Much of the software is for embedded systems.

We want to set up a reasonably convenient way to share internally-developed software/firmware modules among multiple projects. Desirable features include:

  1. To be able to pull shared modules down inside whatever projects use them, and build them in place. (Makes for easy zipping / exporting.)

  2. To have traceability into what projects uses a shared module, if possible. (i.e. To be able to answer the question, "Which projects use FancySharedWidget?".)


  1. I'm thinking a reasonable repo setup / folder hierarchy with svn:externals (with explicit revision numbers) will meet #1 nicely. Right?

  2. Can I meet requirement #2 with svn:externals?

    a. Maybe with a post-commit hook, to track when external svn props are added or modified? Do any such scripts already exist?

  3. Are there better tools approaches for the job? (Preferably in addition to combination with svn. I don't forsee convincing the company to move away from svn , though I'm personally interested in hearing what else is out there.)

4. Meta: does this post belong here, or on Stack Overflow?

  • Your third question makes the post off-topic. Software recommendations are explicitly off-topic here. Also, meta questions should be asked on Software Engineering Meta (where the answer would be that Programmers is the right site for the first two questions). – Bart van Ingen Schenau Jun 9 '15 at 6:25
  • @BartvanIngenSchenau: most parts of this question are IMHO fine for PSE, and I think voting to close it because it contains some off-topic parts is throwing the baby out with the bath water. I took the freedom to make some edits, however. – Doc Brown Jun 9 '15 at 7:39
  • @DocBrown: I didn't feel comfortable making such changes myself, but with your changes I have retracted my close vote. – Bart van Ingen Schenau Jun 9 '15 at 16:47

Externals can be used for what you are trying, but first you should check if you really need them. For our team, it is mostly sufficient to have our shared modules in a folder below named shared_libs, and let all using projects reference that folder by a relative path. However, one will need externals if you are going to have the libs/shared modules in different local folders below your project folder. That way, you can handle situations where you need

  • Project A to reference shared module L version/revision 1.0

  • Project B to reference shared module L version/revision 1.1

both at the same time in local your development environment. By using externals, you cannot just control to have different copies at different locations in your development environment, you get also fine grained control which revision, or branch, or tagged version of the lib/module you want to have placed there.

For us, however, it is mostly sufficient to have different versions of the same lib in our production environment only (we use some externals, but not for the majority of shared libs). For testing and deployment, most of our build scripts pull the compiled results into a test or deployment folder, without the help of SVN.

The drawback of using externals is that you have increased administrative effort - you might need to update explicitly to a newer version of a lib in each project which uses it. For editing and commiting changes your libraries source code directly in the external's checkout folder you will have to utilize the peg-revision mechanism of SVN (or maybe its exactly what you want to prohibit). And if your shared libs are dependent from other shared libs, maybe recursively, you have to make sure the relative paths of all those libs in your local file system are always similar to each other. You will have to validate if this what you need and/or what you want.

Concerning your second question: SVN is not really the right tool for tracking dependencies, the only reliable place where the dependencies are stored are your make files / project files / build scripts / linker files (whatever you use for your build process), so my first suggestion would be to scan those files by a script to collect dependency information. Nevertheless, if you are going to use SVN externals consequently for every shared module dependency, I am sure you can write a script which iterates over the projects in your repo(s) and collects which externals are added there. And I do not think you will need a hook for that, just utilize svn propget svn:externals for this, as shown here.

  • "you cannot edit and check-in your libraries source code in the external's checkout folder." Yes you can. (I tried before posting.) The trick is to revise the externals peg afterwards, and svn update. – cp.engr Jun 9 '15 at 13:19
  • @cp.engr: thanks for the hint, was not aware of that. Changed my answer accordingly. – Doc Brown Jun 9 '15 at 13:46
  • svn propget -R svn:externals is the reverse of Q2. It tells which externals I'm using in a project. I want to know in which projects am I using a library. AFAIK, creating an svn:external does not "register" with the thing being referenced, thus I think I'd need the hook script. – cp.engr Jun 9 '15 at 15:24
  • "the only reliable place where the dependencies are stored are your make files / project files / build scripts / linker files (whatever you use for your build process)". Suggest examples, or links or search terms so I can learn more? Our build processes and environments vary among projects. – cp.engr Jun 9 '15 at 15:30
  • 1
    @cp.engr: concerning reverse dependency lookups: that's why I wrote write a script which iterates over the projects in your repo. Just fill a dictionary, use the library name as keys, use the list of projects where this library is used as values, and populate that dictionary from the output of "svn propget -R svn:externals" for each project. Should be not too complicated, I guess. – Doc Brown Jun 9 '15 at 15:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.