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

Answer 1

I had similar issue. I was trying to create another branch in DEV (in separate folder) from MAIN and this error popped up.

What resolved this problem for me was to create a new branch in the root and later move it to Dev.

Answer 2

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.