Team Foundation Server 2010 branching setup

We're setting up a brand new TFS 开发者_StackOverflow2010 server, without having used TFS before (or, frighteningly enough, no other central source management system). Here's the general structure our small team (of 6-7 programmers) talked about setting up, and I'm curious, based on others experience working with TFS, if this is a good idea or not (these names are just descriptive and not what we're planning to use):

$/
    Our Organization's Collection/
        .Net technology projects/
            class libraries projects/
                Project 1/
                Project 2/
                Project 3/
                etc.../
            ASP.NET projects/
                Project 1/
                Project 2/
                Project 3/
                etc.../
            Windows Workflow Foundation projects/
                etc.../
            WPF projects/
                etc.../
        Other non .NET source code/
        SQL/
        Server configuration/

(and so on)

Will we regret this structure after a year of using it? An application would span many parts of this structure - would that be a problem to manage?

At what level do we set up release/main/dev branches?

Thanks for any input and guidance!

Plan now. Branch when necessary.

With a team that has never managed branching/merging, I wholly recommend keeping everything as simple as possible to start (meaning, forget branching for the short term). After having recently converted our source from VSS to TFS2010 and implemented a Branch By Quality strategy for a team of a similar size with similar experience levels, my recommendation is this:

Do not implement a branching strategy until you need it. You can always branch once you determine it is necessary. Go ahead and bring the projects into TFS for source control and make sure everyone is comfortable with the software and the teamwork necessary to keep it stable.

In the meantime find members of the team who are interested and give them time to research, train, test, and practice on a parallel or simplified instance of your codebase. They will need practice creating projects, branching and merging in situations that mimic your deployment process; they will need time to communicate with the rest of the team to fine tune your processes and DOCUMENT them; they will need to be willing to be a resource to other members of the team as the learning curve flattens out. This way you have team members prepared and confident to step up and implement your chosen branching pattern.

You do not want to jump into a branching strategy before determining the need for it. There is a large amount of administrative overhead involved with plenty of perils.

With that said:

I don't think you will have any trouble managing what you have there once you start branching to accommodate a need. The key here is to make sure you don't over-architect this and complicate the management of your source/deployment. Also know that the structure of your TFS will be reflected in your local file system / workspace.

We created a separate Team Project for each independent solution or group of related reused libraries. In one case we grouped a set of highly dependent solutions together under a single Team Project - a large multi-application intranet portal that is deployed at once. Doing so allows us to keep deployment and source management simple. Here is a look at our branching structure for this one at a high level:

This is one large project with many sub-projects. Every branch is a complete copy (just the difference/versions are stored on the server). There are a large number of Team Projects above and below this one in the Collection and looks a lot like your list up top.

The final answer depends on the interdependency, structure, and deployment strategy of your applications. Do you have any specific concerns regarding your structure there?

In addition to @hangy's link, if its TFS 2010 your settingup then codeplex's Visual Studio TFS branching guide details the current wisdom for 2010.