RE: svn:externals - process question

As you've discovered, externals *always* pull in the HEAD revision unless you specifically add a revision number to the svn:externals property. Needless to say, "rogue" svn:externals are bad for build reproducibility and tagging.

Options are:
Audit the svn:externals (either manually, via a check-in hook, in the build/tagging script, etc.) in your checkedout/exported code to check for "rogue" svn:externals that are not locked down to a specific revision number. If there are "rogue" svn:externals, then you'll need to branch/tag and update the svn:externals before doing your build, or reject the code drop until the svn:externals are fixed. Another similar alternative as you've stated, is to only allow svn:externals that point to tagged code.

If you want don't want to validate externals on the front end, you can try recording the externals after the fact. If you do a checkout of the code, you can cd into each external and get the revision number (via svn info.) Or you could parse the output of "svn co" or "svn export" to get the revision numbers of the externals items and record them somewhere. ("svn update" will also return the revision numbers of externals.) Ex: Create the tag, run "svn co tag", record the revision numbers pulled in, go back and add "-r 123" to the svn:externals in the tag branch. However, I haven't checked how nested externals are handled, e.g. your external reference could contain svn:externals which could have svn:externals of their own, ad infinitum.

A really simple option is to export the code (including externals) and then import the code again as its own tag. Needless to say this breaks history, but it does guarantee that you can reproduce the build.

Using "--ignore-externals" isn't normally practical.
Received on 2013-01-31 21:19:38 CET