Question

At a previous workplace we used svn externals to update dependent projects when a shared component was updated. This made it easy to see anything that those changes broke, as well as update dependent projects to the latest version of a shared component automatically without any intervention.

At a new workplace we are using cc.net with surround scm and I m trying to find something similar in surround. I haven t found anything like externals, only "shared files", but unlike externals, the shared files doesn t allow you to point at a specific revision of a file for the external.

I m interested in what other people are doing in these scenarios to lean on their continuous integration and treat it more for integration than a "continuous build" server. Does anyone know of a tool or something to do "externals" behavior without using svn?

I suppose having an xml registry file of which projects depend on which assemblies and if they should be using the latest version but this seems like overkill.

Answer 1

Personally, I think having externals (or someting like it) in the version control system is a bit strange and actually rather prone to errors. I greatly prefer to use the build system (ant, make, etc) or the continous integration system (hudson, build bot, etc) for that purpose.

Using the build system, I just put the "common parts" somewhere they can be fetched (with wget, curl or simply cp) and have a target that checks if a local (sometimes even checked in to the local project) copy is up to date.

Using the continous integration system, at least Hudson can easily check out directories from multiple repos for a single build. When using this aproach, I also have that other directory checked out for local development, and marked as a "project dependency" in eclipse.

友情链接