version control - TFS2010 Branching into a subfolder of another branch

Question

We have a folder structure in our source control where some things are branched, and some aren't.
The branched stuff follows a (standard?) pattern of Production, Main, Development branches plus the occasional branch for a large project.

Sometimes as part of those large projects web branch some of the stuff that is normally not branched. For instance we might branch $/source/Libraries/LibraryA into $/source/branches/Project1/LibraryA to make some major Project1-related changes to it.
Then when Project1 is nearing release, we reverse integrate both from Project1 into the Main branch, and from Project1/LibraryA into the Libraries folder.

Well, that's how we did it in TFS2008. Recently we moved to TFS2010 which seems to keep track of what things are branches and what aren't. So when we try to branch LibraryA as a subfolder of Project1, we get and error message that Project1 is already a branch.

Is there a way around this? Are we using TFS2010 wrong, and if so, what would be the right way?

Answer 1

As I detailed in "Team Foundation Server and branching characteristics, compared to others", the branching model of TFS has evolved quite a bit between TFS2008 and TFS2010.
The TFS Branching Guide and Branching Guidance can help.

See this thread for more details on branch management:

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)

W 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.

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.

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).

See also this thread with a scenario closer to your situation.

For shared libraries, I generally prefer using file references rather than project references.
I would have a separate TeamProject for developing the source code for these libraries.
You could deploy the assemblies to a shared folder and reference these assemblies from the various projects that use them.
This approach would permit you to have multiple versions of the assemblies. Each project would create file references to the particular version they require.