Branch selectively in TFS

Question

We are allowing external consultants to work on a portion of our source. We created a new TFS project and granted them rights to that. Branching does work between TFS projects, so we can branch the "real" TFS project they're working on to the consultant project. However, we only want to expose portions of it. Here's what we want (simplified):

OurProject
  Mainline
    Applications
      Secret1
      NewApp
    Libraries
      Secret2
      Shared

ConsultantProject
  Mainline-Branch
    Applications
      NewApp
    Libraries
      Shared

If we simply branch Mainline and delete the Secret folders on the branch, merging back must be done carefully to avoid deleting the Mainline Secret folders. We want to simplify future merges (both ways) while minimizing risk.

How can this be accomplished?

Answer 1

Instead of branching and then deleting files/folders from the branch, branch only the files that you want them to have access to.

eg:

• Branch Mainline -> $/ConsultantProject/Mainline-Branch.
• Right click on $/ConsultantProject/Mainline-Branch/Applications/Secret1 and undo your checkout.
• Similarly undo checkout on $/ConsultantProject/Mainline-Branch/Libraries/Secret2.
• Check in your branch ($/ConsultantProject/).

With this completed, merges from one to the other will not affect the files/folders that you didn't branch.

Answer 2

TFS really likes for all dependencies of a project to be inside one folder. I would restructure your folder layout quite a bit. Here's how I would do it.

TeamProject
    SecretApplication
        SharedLibrary1
    Application1
        SharedLibrary1
    SharedLibrary1
    ConsultantApplication1
        SharedLibrary1

Here's the detail...

Notice how all the apps are peers? SharedLibraries are shared/branched into the apps that use them. That way apps can move forward at their own pace and pull down shared changes at their own pace, and merge their changes to shared code back at their own pace. TeamProject->SharedLibrary1 is the "mainline" for SharedLibrary1. Everywhere else you see SharedLibrary1, it's a branch. Each application folder is its own "mainline", making your structure more app-centric than "all our work" centric.

With this setup, you merely make a branch of Application1 and call it ConsultantApplication1. That way you can setup your security to allow your consultants to only see that one app and all its dependencies. They can merge and pull at will. Well, they won't be able to merge without seeing the source project, but you can. All other apps in your team project will be invisible to them.

Let me know if I've misunderstood something or there are some requirements preventing you from using a structure like this. If there's a secret shared library under Application1, we'll have to think on this some more, but I think that would have compilation issues anyway. Regardless, placing all dependencies for an app under a single folder helps a ton and is a great practice.

Answer 3

I know this may not be answering your question, but rather the intent of your question. Why not just set permissions to hide those secret items from the consultants and branch as you would any other time?

Answer 4

I agree with Alex. TFS doesn't have any built-in mechanisms to handle sparse branches. The closest analogue in TFS is branching/merging by label, but that strategy brings a ton of management overhead which is very error prone.

So, just let the branch/merge system do its thing and use ACLs to ensure your consultants can't see the Secret Sauce.

Note that for complete security, you'll need to create a 2nd solution for them that does not include any of the Secret projects, then ACL the main (all inclusive) solution out of sight. Do any non-Secret projects depend on the Secret projects? If so you'll have to do something similar (though slightly more involved).