We are moving to TFS 2010 (from PVCS) for source control and work item tracking
As I understand it you should have under source control for each TFS project everything that projects solutions, etc. need to build.
This OK for new .NET solutions/projects, but we have a large collection of legacy Delphi 6 projects with shared source libraries we want to port into TFS for source control and build. It is how we manage multiple TFS projects that want to sare a specific set of source files between them that is my problem here.
Historically with PVCS we have had projects for each solution (say A & B), and a seperate project for common source code (say C). Users would get C then get either A or B (checking out as required) on disk this would maifest as something like this:
$\Projects\C
$\Projects\B
But B & C are seperate PVCS archives.
Now fast forward to life with TFS 2010 as our ALM solution…
If we create a TFS project (1) that contains the source repository for the common code (C), that projecs can obviously access it (lets say the TFS project also contains the solution A) and all is good.
We now create a new TFS project (2) in which to make solution B. Beacuse solution B is wildy different to solution A we had no reason to share TFS project 1’s source control so we made a new source repository rather than branching from 1. Now later on we discover a need for solution B to access some common files from C (in 1). Oops!
The question is this; can I perform some source control wizzardry that lets me add a folder in the 2’s soruce control that is a (to steal a file system term) symbolic link into 1’s source control for the common code C?
Edit
I should point out this is all legacy code and the shared source library (C) is just that shared source it does not build into a library or other binary we could simply add to A or B.
In TFS 2010, as you may know, they introduced the concept of a project collection (PC). Each project collection is an aggregate for team projects (TP). Each PC is stored in a separate database, and the VCS is stored in the database.
This means that there is one VCS repository per PC, not TP. Each TP is (by default) the root folder in each VCS (i.e. TP1 will be at $/Prj1, TP2 might be at 4/Prj2, etc.)
One more point is that you do not want to have one solution per TP. Think of a TP as a suite of products, and a solution as a part of that.
Symbolic links, as per Visual Source Safe, no longer exist in TFS, and I’m not sure you need them. It is not considered a good practice to create a dependency between one solution and the source code of another solution.
What I suggest you do, is have each solution in your codebase depend only on its own code, and on other solutions’ binary deliveries.
What will happen is that if Sln_A depends on Common_Sln, you will build Common_Sln, and bring its binaries from the drop location as part of your Get. Then, add the binaries as references.
This will solve your problem, with the added benefit of transforming a tight coupling where a dependency may break your dependent solution’s build, into a situation where you do not change or upgrade your dependencies until they are ready and you are ready for them.
Does this help solve your problem? This is how I do this with the projects I consult on.
HTH,
Assaf.