We are starting a new SOA project with a lot of shared .net assemblies. The code for these assemblies will be stored in SVN.
In development phase, we would like to be able to code these assemblies as an entire solution with as little SVN ‘friction’ as possible.
When the project enters more of a maintenance mode, the assemblies will be maintained on an individual level.
Without making Branching, Tagging, and Automated Builds a maintenance nightmare, what’s the best way to organize these libraries in SVN that also works well with the VS 2008 IDE?
Do you setup Trunk/Branches/Tags at each library level and try to spaghetti it all together somehow at compile time, or is it better to keep it all as one big project with code replicated here and there for simplicity? Is there a solution using externs?
What we did at our company was to set up a tools repository, and then a project repository. The tools repository is a Subversion repository, organized as follows:
Every time we get a new version of a tool from a vendor, it is added under its vendor, name, and version number, and the ‘latest’ tag is updated.
[Clarification: this is NOT a typical source respository — it’s intended to store specific versions of ‘installed’ images. Thus /svn/tools/nunit/nunit2/2.4 would be the top of a directory tree containing the results of installing NUnit 2.4 to a directory and importing it into the tools repository. Source and examples may be present, but the primary focus is on executables and libraries that are necessary to use the tool. If we needed to modify a vendor tool, we’d do that in a separate repository, and release the result to this repository.]
One of the vendors is my company, and has a separate section for each tool, assembly, whatever that we release internally.
The projects repository is a standard Subversion repository, with trunks, tags, and branches as you normally expect. Any given project will look like:
The tools directory has a Subversion svn:externals property set, that links in the appropriate version (either a specific version or ‘latest’) of each tool or assembly that is needed by that project. When the ‘foo’ project is built by CruiseControl.NET, the publish task will populate the ‘publish’ directory as the ‘foo’ assembly is intended to be deployed, and then executes the following subversion commands:
Developers work on their projects as normal, and let the build automation take care of the details. A normal subversion update will pull the latest versions of external tools as well as as project updates.
If you’ve got a lot of tool interdependency, you can configure CruiseControl.NET (by hand) to trigger builds for subordinate projects when their dependencies change, but we haven’t needed to go that far yet.