Randy in Marin
We are skipping TFS 2008. Is there a direct upgrade path planed from TFS 2005 to TFS 2010?
We have just purchased TFS for our organization. I just read "The Build Master" by Vincent Maraia. I have many questions, and almost know where to start. Here are a few. I'd appreciate any response. Perhaps you can forward this to those that might be generating the guidance mentioned in the video.
1) I'm trying to create a recommendation for a standard folder and branching structure. It would be nice to have a common pattern to follow. Does it make sense to use a "Goldline", a mainline (e.g., VBL), and branch folders? How does this look?
Branch (branched from Main as required - FI/RI from main as needed)
BugFix (contains a branch for each bug?)
Feature (contains a branch for each feature)
Release (contains a branch for releases, as needed)
Gold (always ready for the client - FI/RI from main when good)
Main (branched from Gold - normal location for development)
Under Gold and Main would be the solutions required by the team for the project. Do BugFix branches come from one location (e.g., Main) or several? Is it redundant when branching releases and features?
2) If later a new project or solution is required, is it added at the lower level (e.g., Main or Feature) and then merged into the higher levels (e.g., Gold or Main)?
3) The P&P guide "Team Development with Visual Studio .Net and Visual SourceSafe" makes it clear that project references are "better" than file references. Project references insure the latest version is used without having to manually update the reference. If a file reference is used to load a library common to several projects, is it possible to automatically use the latest version? Will the references have to be manually maintained?
4) This is related to the last question, but more TFS specific. We have several teams working on diverse projects (e.g., mainframe conversion using cobol.net, property, courts, etc.). We plan to use a team project for each large application (e.g., a new court system). However, there will be some common code for several projects (e.g., CSLA, CAB, etc.). Is it a bad idea to place and maintain the common code a separate team project? Can the code from one team project be branched into another team project? If not, would defining a special workspace to get the code be a bad idea? I'm trying to use project references. Perhaps I should not?
5) The P&P guide "Team Development with Visual Studio .Net and Visual SourceSafe" also states the local working directory structure should match the structure in VSS. Does this apply to TFS?
6) Should only one workspace be defined per TFS? For example: $/ maps to "My Documents\TfsServerName\". This would let multiple users use multiple TFS instances on one client. Will TFS have the same issues as VSS if two users accidentally share a workspace?
And then there is the daily build....
I think these are hard questions. Unfortunately, I have to come up with answers. Perhaps you can point me in the right direction.
PS I watched the video twice. Thanks for the info.