2

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.

Mogsdad
  • 44,709
  • 21
  • 151
  • 275
Pete Stensønes
  • 5,595
  • 2
  • 39
  • 62

1 Answers1

5

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.

Assaf Stone
  • 6,309
  • 1
  • 34
  • 43
  • Thanks Assaf I had missed the PC being the source container. That may well help. However the code I'm discussing is legacy Delphi code and as such this shared code does not build into its own binary which I could add to the other projects source tree. **sigh** – Pete Stensønes Feb 21 '11 at 17:59
  • Hi Pete, Don't worry about legacy code. if you use (and you really should) the TFSBuild to build your delphi code, you can take the binaries from the build's drop folder. Just so you know, with TFSBuild you can run any command at command line, and delphi has a command-line compiler. It just takes an" Invoke Process" build activity. Does this solve your issue? – Assaf Stone Feb 22 '11 at 04:43
  • Getting our delphi projects building with the TFSBuild is one of my firs jobs (actually we need 3 InvokeProcesses - one to run a PERL script to make a DCC32.CFG file from Delphi IDE project files, one to do the build & link (DCC32.exe) and one to strip the binary of unncessary TD32 debug info (TDSPACK)) – Pete Stensønes Feb 22 '11 at 09:12
  • I think the big pain point here is that the common code is currently used as just that shared SOURCE code, so I cant take any form of binary for the common code and link to the other projects, they share source. – Pete Stensønes Feb 22 '11 at 09:13
  • I'm beginning to think I may just have to suffer teh pain of altering all 140 legacy apps to use a runtime package, and generate that from teh common code project, then I could just add that as if it were a thrid party library to the other projects. I was really hoping to avoid that with a fancy source ocntrol tric to link a known folder/branch of the common project into the other two projects source trees. – Pete Stensønes Feb 22 '11 at 09:15