This project has moved and is read-only. For the latest updates, please go here.

How to prevent new branch creation in TFS2008

May 25, 2010 at 4:38 PM
Is it possible to prevent a developer from creating branches in TFS2008 while still allowing them to check-in and check-out from the working branch?
Jun 4, 2010 at 4:16 PM


I guess I need to know the same thing but only from a TFS 2010 standpoint.   We do not have TFS in production as of yet but we have been using VSS 2005 ( huge change for us).   I have been testing out the branching and merging functionality and have ran into the same issue. 

Maybe I should have done this but I have two members defined to the project as Project Admins ( Admin1,  Admin2) The first Admin1 under the project created the Main Branch folder and copied a sln from VSS to TFS under that project and Main Folder.    Admin1 then had that sln become a branch.   


Now Admin2 comes in and right clicks on the MainBranch and does a "Convert To Branch"   an error message comes up of TFS203028 that Branch Already Exists at    such of such workspace that was owned by ADMIN1. 

First of all I also want to share the structure of the MainBranch, DevBranch and a FixBranch with all the developers that need access to that Project.    I don't want them to go out and create separate Branches where ever.

Secondly, when this situation happens how can an Adminstrator or even the Project Administrator go back and fix this mess.  

I am a bit confused also. 



Jun 4, 2010 at 4:48 PM
Edited Jun 4, 2010 at 4:52 PM

The answer to this question is different for TFS 2010 vs. TFS 2008.

In TFS 2010, a user must have Manage Branch permission set to Allow for a given path to do the following:

  • Convert folders to branches (and branches back to folders)
  • Update metadata for a branch (i.e. owner, description)
  • Create additional child branches from the original branch
  • Change the relationships between branches with merge relationships (i.e. reparenting branches)

In TFS 2010, a user must have Merge permission set to Allow for a given path can do the following:

  • Pend merge operations on branches, folders, and files under the specified path

Manage Branch and Merge permissions are new for TFS 2010.

In TFS 2008 users must have Read, PendChange (aka Edit or Check Out ), and Check in permission set to allow in order to do branch and merge operations.

  • Read permission is required to discover items to be branched and/or merged
  • PendChange is required to perform a branch or merge (which creates a pending changes)
  • Check-in permission is required to commit (check-in) the pending changes.

Permissions can be set at the item level (even on a single file).

Bill Heys
VS ALM Ranger




Jun 4, 2010 at 4:55 PM

To further elaborate, in TFS 2008 if you grant need to grant developers Read, Check Out, and Check-in on the branches they are working on.

Having done that, you probably cannot prevent them from creating new branches from those where they have permission.

You can deny developers permission on other branches to prevent them from branching and merging branches they should not be touching.

Bill Heys
VS ALM Ranger

Jun 4, 2010 at 5:45 PM

This is great.  This fits in nicely with how we are trying to convert.   Couple of additional questions:

1.  Is there some kind of Security Quick Start Guide that I can use to at least get certain groups defined and setup initially.

2.  From my previous mess-up of creating a Branch two different ways with two different users, is there a way to clear the branching a start from scratch.   With my scenarios as Admin1 doing one thing and Admin2 doing another on the same project and folder.  


Thanks for the prompt feedback.

Jun 8, 2010 at 6:36 PM

I am not sure how you ended up creating a branch *two different ways* for two different users.

Branching in TFS 2010 is a server-side operation. Presumably, if you have a team of developers and you grant them check-in and check-out permissions without merge or manage branch permissions - these developers would be able to create workspaces that map whatever branches they need to work on to local folders on their hard drive.

Having a smaller group of people, such as a technical or senior develper with branch permissions - merge and manage branch would help to ensure that your branching strategy is implemented correctly (according you your requirements and best practice recommendations).

As for cleaning up a *messed-up* branching structure, there are probably several options. If you want to start from scratch, you can probably create a new branch - to serve as your Main branch. When you do this, you need to be careful that any changes in existing branches are checked in and merged into the branch that will become the Main branch. Be aware that, while it is possible to delete or rename existing branches, you need to be careful going down this road. You do not want to lose changes (and you may not want to lose change history).

I am not sure I totally understand how your branching structure got *messed up* or what it looks like right now. For example, you state: "The first Admin1 under the project created the Main Branch folder and copied a sln from VSS to TFS under that project and Main Folder.    Admin1 then had that sln become a branch.  "  I am sure you are not suggesting that Admin1 converted a a solution file to a branch. It is possible you meant to state that Admin1 clicked on a folder (called "Main" or "Main Branch") and converted that folder to a branch. That would certainly explain why Admin2 could not convert this folder to a branch ... it is already a branch.

Bill Heys
VS ALM Ranger



Jun 8, 2010 at 7:19 PM

I was mistaken in my previous post.  

What Admin1 did was created additional folders under the Main branch and called it XXXX(solution name)Solution-Branch. Then created another folder called XXXXX(solution name)Solution-Branch2.  Under the Main branch there are multiple Solutions for this Project so each has been put into a folder called  that solution name and branch and branch1. 



   +XXXXSolution-branch     (this is a branch)

   +XXXXSolution-branch-2  (this is a branch)

When Admin2 tried to take the MainBranch folder and "Convert to Branch" he got the error message that I originally wrote about. 

So if Admin1 has a different Branching concept than Admin2, the Branching structure could get really "messed up". 



Jun 8, 2010 at 8:40 PM

I think it is important, as you describe your current situation, to carefully distinguish between folders and branches. In VS 2008 it was much more difficult, in Source Code Explorer, to see which folders were containers of other folders, branches, and files, and which folders had actually been created through a branching operation.

In VS 2010, Branches are now a first-class object and as such have a branch icon that easily distinguishes a branch from a folder (with a folder icon).

It is also important to have a standard approach to setting up new Team Projects in VS 2010.

For example I generally start in the Team Explorer by adding a new Team Project (<TeamProjectName>) to TFS. After it creates all of the nodes in Team Explorer, I double-click on the Source Code node to open the Team Project in Source Code Explorer.

Initially, a new Team Project will not be mapped to a workspace. The workspace defines a mapping between a Team Project and folders on your local hard drive. I generally create this mapping first. I would map the Team Project to a folder such as c:\VS2010\<TeamProjectName>\

If prompted to do a get latest, I click yes, to ensure that my local folders bring down all of the contents of <TeamProjectName> from TFS. In the case of a new Team Project, this should not be necessary, but I do this anyway.

At this point, I create my first folder under the Team Project, called Main. This will initially be a folder, but I will soon convert it to a branch. After adding the folder, I check-in any pending changes. I typically check-in pending changes frequently as I am setting up the Team Project. For this reason, I often keep the Pending Changes window open.

Next, I might some folders (for example “Bin”, “Source”, and “Docs” under the Main Folder… Check-in these changes.

Next I add my solution under the <TeamProjectName>\Main\Source folder… and Check-in these changes.

Once I have created my initial solution, then I might create my first child branch of Main. To do this, I first convert Main from a folder to a branch (VS 2010 only).

Then I right click on the Main branch and create a new child-branch. I might put this new branch into a Development container folder. So I branch $<TeamProjectName>\Main to $<TeamProjectName>\Development\DevTeam1. Note Development is created for me If it did not exist and is now the container folder for the child branch DevTeam1.

If I had a second Development team, and I needed isolation between the two development teams, I might create a second development branch. Once again, branch from $<TeamProjectName>\Main to $<TeamProjectname>\Development\DevTeam2. Note since Development is a folder that already exists, it will simply add this new branch, DevTeam2 to this folder.

Note the differences between the icons for folders, and branches.

After you branch from Main to DevTeam1, you should notice that the folder structure under Dev is created under DevTeam1, and the solution should be under the source folder in DevTeam1.

If you right-click on a branch in the Source Code Explorer, you should be able to see the properties of the branch.. including it’s hierarchical relationship to other branches.

Now here is the important concept. In VS 2010, you cannot nest branches within other branches. Currently, if you have followed the steps above, you should have three branches (Main, DevTeam1, and DevTeam2.) The hierarchy should show you that DevTeam1 and DevTeam2 are siblings in that they are both full children of Main. But this does not mean they are nested within the Main branch.

If you were to attempt to convert a folder under any existing branch from a folder to a branch, I would expect you would receive an error regarding nested branches.

For this reason, I believe when you try to convert Main from a folder to a branch, you are essentially converting a container folder (of other branches) to a branch, and that won’t be permitted either.

As a general rule I think it is better to branch from existing branches .. than it is to create folder within folders and then try to convert them to branches.

Further, If Admin1 converts the folder MainBranch from a folder to a branch, then Admin2, should do a get latest and it would also be a branch for Admin2. You should not have to users looking at the same Team Project where one users thinks MainBranch is a branch and another user thinks MainBranch is a folder. If that happens then one user has not done a get latest to be sync'd with changes made on the server by other users.

Finally as a naming convention... you probably would not have the word "folder" in the names of folders of your hard drive.. it should be obvious when you use file explorer that something is a folder vs a file.

For the same reason, you probably don't want to put the name "branch" onto a folder or branch in TFS. It is possible to convert a folder to a branch or vice versa. The icon should be sufficient to tell you it is a branch... without adding a suffix to the name.

I hope this helps explain your scenario, and gives you some hints for starting in a better direction.

Bill Heys
VS ALM Ranger

Jun 8, 2010 at 9:05 PM

It has.  Luckily we are still in test mode and everything installed in a separate environment. So we are trying to determine best practices as we move forward.  Your help is much appreciated.