I'm currently evaluating TFS 2010 for use in our development team as the source control solution instead of Git. We're a Microsoft shop, dipping our fingers into Sharepoint and Project Server anyway so it would be nice to have it all running in one platform.
My problem starts with this...
In Git, we have a development model that sees our Company's OWN re-usable code-base stored in a separate repository. Each client solution also has its own repository and a sub-module (extern for SVN-junkies) linking it to our common library. In order to allow for developers to add functionality to our common library as they go, we set up a tracked branch for each sub-module and merge the bits of functionality into our common-library as they are finalised.
So (in a kickback to old ascii art) a rough representation of our Git set up would be...
Common-Library::(branch) -----> (submodule)::Client-Solution
^ |
|-----------------
This structure is very important to our effectiveness. It allows developers to update our common libraries in context, in solution, at the same time as they develop their client solutions. More importantly, it allows newly developed functionality to find its way back into our common library in a requirements driven, organic manner by merging from the client branch back into the master and into other client solutions.
My problem is that I really want to use TFS 2010 for all the other workflow good stuff, but I'm having a hard time getting my head around how such a model could fit into its Source Control capability. It seems pretty stand-alone. So far, I can't find anything describing how to set up external references such as 'submodule'.
- Does TFS 2010 have such a capability?
- Perhaps my understanding of TFS 2010's model is falling short?
- How would you set up a shared common library model in TFS 2010?
If I understand you correctly, you can map this in your local workspaces if you have say:
$/.../Projects/YourProject
and
$/.../Libs/LibA
You can set your local workspace to
Status Source Control Folder Local Folder Active $/.../Projects/YourProject C:\..\YourProject Active $/.../Libs/LibA C:\..\YourProject\Libs
So your libraries can exist anywhere in your TFS project, but locally they will be available in a reasonable location for you to add to your solution. Any changes you make can then be saved correctly in the respository, and anyone else working using those shared projects will see it locally in their workspace when it's updated.
Update:
If you want to use branched version, say you have
$/.../Customer1/Libs/LibA
and
$/.../Customer2/Libs/LibA
Both are branched off
$/.../Libs/LibA
If you're doing work for Customer1, then you change your mapping from
Active $/.../Libs/LibA C:\..\YourProject\Libs
to
Active $/.../Customer1/Libs/LibA C:\..\YourProject\Libs
Everything should still be in the same place as the Local Folder hasn't changed.
(tbh, this isn't an brilliant example, but I hope it makes it a bit clearer or gives you some ideas!)
Is such a structure a way for you to go?
Now you can start your Client 1 and branch the mainline of Common Lib A to Client 1/devline/Common Lib A
If you made changes in the Common Lib A and are finished you can merge the branch in Client 1 with the mainline or possible better an integration line.
An other solution is to use the common lib in client applications as assemblies which I prefer.
If I come in the situation that something is missing in the Common lib I create a new requirement/backlog item for the common lib (it has an extra area path) and implement it in the branch of the Common Lib A, test it and deploy it to my application(s).
You can take a look at the branching guide if not already done, perhaps you get more ideas.
Edit based on comment
When you branch you can specify the folder via browse.
There you select your target branch.
After done that, you can add the sources of Common Lib A in you client solutions.
来源：https://stackoverflow.com/questions/8757186/how-do-i-model-a-central-library-in-tfs-2010