views:

246

answers:

3

I'm looking into svn externals for my company, and it seems like it would be a good feature for us to use. We have several products that often reference shared components, but have a bad habit of falling behind into older versions and even differently branched codebases sometimes.

I've read a decent bit about how they work now, and I think I understand the concept OK. What I'm not 100% sure on is how different revisions of multiple repositories link together.

Let's say I have a Product and a Library. The Product is built against the Library, so its repo has a svn:externals property that links to the Library source. In the absence of a specific version in the svn:externals definition, when I check out HEAD of Product I also get HEAD of Library.

I build several versions of Product over the years, each time referencing the latest version of Library. One day though I have to go back and check out Product version 1, by manually selecting the correct revision. When I do so, which version of Library do I get, HEAD or the revision that I used when I built it the first time?

Hopefully I've been a good developer and remembered to tag every version of Product that I release. When I apply my tag 'Product-1-0-0' to the repository, does the correct revision of the Library repository get tagged too? If I later check out Product based on the tag 'Product-1-0-0', does the correct revision of Library get checked out with it?

+4  A: 

What you have to watch out for with svn:externals is that you need to explicitly specify the revision if you want something other than trunk. Google "pinning svn:externals" for the details. If you are using a fairly modern version, 1.5 or newer IIRC, then relative externals are at least supported. Older versions, like the one that I am currently using, requires us to explicitly pin the revision using the -rNNNNN option on the svn:externals property for every damned folder.

We ended up using a modification of a perl script named svncopy.pl from tigris.org to do all of our branching and tagging. It's not that bad but I wish that we had known how much work it was before we decided to use them so heavily.

D.Shawley
+4  A: 

You can use date specifiers to ensure you get corresponding revisions when you update.

We've done it for a tool that runs PC-Lint; we like to run it on each revision so that we can diff the results.

It's a bit obnoxious in its implementation -- we:

  • determine what rev the working copy is at (using svnversion)
  • determine what rev the HEAD is at (using svn info)
  • grab the timestamps for all revisions up to and including head (using svn log)
  • bump the timestamps by .999 seconds to be "sure" we get the rev (yay magic!)
  • update to each revision (using svn update -r {sometimestamp})
  • run PC-Lint on the working copy, diff, mailout, trigger klaxons, whatever

(Complexity worthy of Rube Goldberg, isn't it? Upvotes and undying gratitude for anyone who can suggest a better solution.)

You may also be interested in the svn book's section on Peg and Operative Revisions, which I've just discovered -- this seems to be a relatively new addition.

leander
+1  A: 

Yes it will, assuming you provide an explicit revision number in your externals, as suggested in the docs. Otherwise it will use HEAD revision of externals referenced.

Just watch out for file based svn:externals in 1.6. They look very useful, but I just hit this bug today :(

Si