tfs - Team Foundation Server 2010 branching setup -


we're setting brand new tfs 2010 server, without having used tfs before (or, frighteningly enough, no other central source management system). here's general structure our small team (of 6-7 programmers) talked setting up, , i'm curious, based on others experience working tfs, if idea or not (these names descriptive , not we're planning 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 on)

will regret structure after year of using it? application span many parts of structure - problem manage?

at level set release/main/dev branches?

thanks input , guidance!

plan now. branch when necessary.

with team has never managed branching/merging, wholly recommend keeping simple possible start (meaning, forget branching short term). after having converted our source vss tfs2010 , implemented branch quality strategy team of similar size similar experience levels, recommendation this:

do not implement branching strategy until need it. can branch once determine necessary. go ahead , bring projects tfs source control , make sure comfortable software , teamwork necessary keep stable.

in meantime find members of team interested , give them time research, train, test, , practice on parallel or simplified instance of codebase. need practice creating projects, branching , merging in situations mimic deployment process; need time communicate rest of team fine tune processes , document them; need willing resource other members of team learning curve flattens out. way have team members prepared , confident step , implement chosen branching pattern.

you not want jump branching strategy before determining need it. there large amount of administrative overhead involved plenty of perils.


with said:

i don't think have trouble managing have there once start branching accommodate need. key here make sure don't over-architect , complicate management of source/deployment. know structure of tfs reflected in local file system / workspace.

we created separate team project each independent solution or group of related reused libraries. in 1 case grouped set of highly dependent solutions under single team project - large multi-application intranet portal deployed @ once. doing allows keep deployment , source management simple. here @ our branching structure 1 @ high level:

large intranet solution

this 1 large project many sub-projects. every branch complete copy (just difference/versions stored on server). there large number of team projects above , below 1 in collection , looks lot list top.

the final answer depends on interdependency, structure, , deployment strategy of applications. have specific concerns regarding structure there?


Comments

Popular posts from this blog

apache - Add omitted ? to URLs -

redirect - bbPress Forum - rewrite to wwww.mysite prohibits login -

php - How can I stop spam on my custom forum/blog? -