As many of you know, Branches are now a first-class object in TFS 2010. In Source Control Explorer, it is now very easy to visualize the difference between a branch and a folder. Folders are now used exclusively as containers of branches, files, and other folders. The MatureSourceTree example below shows how TFS 2010 represents a branch with a new icon. It is now much easier to understand the physical arrangement of branches and folders.
I recommend adopting a naming convention for branches and folders. In the example above, each Release branch (Service Pack, Hotfix, and Release) includes the Version number, Service Pack number, and branch name. Note that in most cases the branches are arranged in folders with Version number and/or Service Pack numbers. While it may seem redundant to have the Version on both the containing folder and the branch name, you will soon appreciate the redundancy. When you view the branch hierarchy, only branches are visualized. Without the folders visible, it becomes challenging to know which Hotfix branch is for V1 vs. V2, etc.
Here is the same MatureSourceTree as shown in the Branch Hierarchy View of VSTS 2010. Here you can see the benefit of including the Version number and Service Pack number on the branch names:
Arranging branches into a folder structure helps organize branches and makes it easier to navigate the source tree in Source Control Explorer. It is not important, in my view, that everyone adopt the same folder structure. In the physical view, above, the Release branches are organized into folders primarily by Version (V1, V1.1, V2, etc.). Within the version folders, the branches are organized by Service Pack number (SP1, SP2, etc.) and then type (ServicePack, Hotfix, Release). There are other ways of organizing branches, such as by type (Release, ServicePack, Hotfix), and within type, by Version. It is less important that you adopt a specific naming convention and folder organization than it is that you try to be consistent within your organization across team projects.