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.
VS ALM Ranger