Team Foundation Server best practice, branch "common" project or grant permission?

Question

Ok, the setup is simple.

Assume we have the following source control hierarchy in TFS $/:

/Common
   /Library1
   /Library2
/ProductA
/ProductB

Now there's a team for every product hence in source control there are permissions on each "product" folder to grant access for that specific team (Product A team has contribute permissions on "/Product A", and so on).

Now any given product (A, B, ...) may use a common library. Do I grant contribute (or read) rights to /Common/LibraryX? Or do I branch a copy for LibraryX to ProductY?

/Common
   /Library1
   /Library2
/ProductA
   /Library1-ProductA (branched)
/ProductB
   /Library1-ProductB (branched)
   /Library2-ProductB (branched)

There may be freelancers or other people in these "product groups". So I want to have tight control over what they can see and what they can modify.

I'd prefer branches. That however probably means a lot of additional work as I have to make sure any deployment doesn't break another application.

E.g. if Library1 was a SharePoint project and it would be part of ProductA and ProductB I'd have to make sure I deploy the latest version (because there can only be ONE - GAC deployment!) and it doesn't break anything.

If I take Library1 out of the deployment process I no longer have working automated builds. Not good either.

Answer 1

The best practice is to use NuGet. Create NuGet packages for each of your common libraries and use the package manager to use them. This way, the "release" of the Common Library would be formalised. If you are adding features to your common libraries, you can make a conscious decision to increment release version and the clients can decide whether they want to upgrade or not.

If you are going down this route, best it to separate branches for each Common library as they would be a product in it's own right.