One of the clients I went to today had an interesting dilemma relating to managing references in source control between projects.
Their situation is not unlike many other companies: they have an infrastructure team that creates regular releases of the basic APIs that many internal projects in the company use to create applications.
The problem is, what happens when a new version is releases and the other dependent projects need to be updated with the new version of the framework? To make this harder - the framework may be composed of many dlls, and some project may not want to automatically accept the new reference to the new version of the framework, but keep building against the older one.
How do you allow an automatic update of the references for dependent selected project?
Team System (which is what they were examining against their current Perforce repository) does not have a solid answer for this. sure, you can do branching, shelving and merging like crazy and achieve this, but there is no simple solution.
Luckily, there is *some* sort of solution for this. It was created by a crazy Australian I got to meet at the last MVP summit, Mitch Denny. You can find his blog over at www.notGartner.com . Mitch created a project called TFS Integrator, that not only allows for creating a continuous integration solution , it allows what he calls "Dependency Replication" :
Dependency Replication is a process that most development teams have to do as the scope of what they are trying to achieve grows. The idea is that within your organization you might have a set of common frameworks that you use and maintain. Rather than linking in the source code into each new project that you undertake you treat the framework like an internal product which you build separately.
The problem you then have is integrating the updated binaries into the other projects that depend on them. This can be quite a time consuming process, so much so that teams will often give up and end up compiling hundreds of different versions of the same code into their code base - which creates a maintenance nightmare.
TFS Integrator includes a dependency replication engine which extends the continuous integration feature. It does this by listening for the build completion even from TFS and using that to trigger the execution of some code which picks up the compiled build output and checking it back into Team Foundation Server in a specified location.
The effect is that with dependency replication the feedback loop is complete and dependant components can be linked together.
It does require a .NET 3.0 runtime installed (it uses WCF under the covers) but if you install it on a separate machine it should be of no particular problem.
If all goes well, TFS Integrator should be able to solve my clients problem.
Another interesting resource for techniques on managing the visioning issues in source control can be found in this blog post, which is quite thorough.