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,
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:
svnversion
)svn info
)svn log
)svn update -r {sometimestamp}
)(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.
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 :(
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.
You should read up on dependency managers - I'm not sure what your platform is, but ivy and maven solve this problem in a much cleaner manner.
svn:externals are not versioned in subversion. if someone changes the revision or tag of one of your externals you have no way of knowing what it was prior to the change.
This article addresses the question nicely...
http://www.simple-talk.com/dotnet/.net-framework/tortoisesvn-and-subversion-cookbook-part-4-sharing-common-code/
Seth