Hello,
I come from a CVS world where a branch is parallel space that has the same structure as the mainline but with different content. I am looking into moving to TFS, but have been struggling lately with the concept of path branching model.
Searching the internet, I found some guidance into ‘path branching model’ best practices; however, things seem to quickly breakdown when I start applying the path branching model to real examples.
Here are my requirements from TFS:
- To be able to reference VS projects across TFS projects
ie $/TeamProjectA/SolutionA/ProjectA
$/TeamProjectB/ProjectB
Solution A references both ProjectA and ProjectB
- To be able to use branching and merging as per the "the importance of branching models in SCM" reference from Buck Hodges’ blog (http://blogs.msdn.com/buckh/archive/2004/06/04/148633.aspx#148851)
So, following the recommendations on the web, I set up my directory in a following fashion:
$/TeamProjectA/Mainline/SolutionA/ProjectA
$/TeamProjectB/Mainline/ProjectB
And when I branch, I do it in the following manner:
$/TeamProjectA/Branches/<branchName>/SolutionA/ProjectA
$/TeamProjectB/Branches/<branchName>/ProjectB
And I set up my workspace mapping in a similar fashion:
$/TeamProjectA/Mainline -> c:\src\Production\TeamProjectA\
$/TeamProjectB/Mainline -> c:\src\Production\TeamProjectB \
This works nicely cause TeamProjectA items can reference TeamProjectB with no problems, and branching also *seems* to work nicely, since it fits in the directory hierarchy very well like so:
$/TeamProjectA/Branches/<branchName> -> c:\src\Development\TeamProjectA\
$/TeamProjectB/Branches/<branchName> -> c:\src\Development\TeamProjectB\
BUT!!!!!!!
When I open the branched solution, modify the solution itself by changing dependencies or modify any source file, the solution and file that gets checkout are the ones located under the mainline, even though I am working on the branched version of the solution and source file.
Does this have anything to do with the fact container files (solutions and projects) have references to paths in the repository
I branched $/Bakala/Mainline to $/Bakala/Branches/ver1 and this is the solution file:
GlobalSection(SourceCodeControl) = preSolution
SccNumberOfProjects = 3
SccProjectUniqueName0 = ..\\..\\Utilities\\Version1.0.0\\Common\\Utilities\\Common.Utilities.csproj
SccProjectName0 = $/Utilities/Mainline/Version1.0.0/Common/Utilities
SccLocalPath0 = ..\\..\\Utilities\\Version1.0.0\\Common\\Utilities
CanCheckoutShared = true
SccProjectName1 = $/Bakala/Mainline/Solutions
SccLocalPath1 = .
SccProvider1 = MSSCCI:Team\u0020Foundation\u0020Server\u0020MSSCCI\u0020Provider
CanCheckoutShared = true
SolutionUniqueID = {7FBDB525-C384-4B1C-9914-2F8B61592312}
SccProjectUniqueName2 = http://localhost/EASWebApp/EASWebApp.csproj
SccProjectName2 = $/Bakala/Mainline/EAS/UI
SccLocalPath2 = ..\\EAS\\UI
CanCheckoutShared = true
SccProjectEnlistmentChoice2 = 2
EndGlobalSection
Notice all the reference to Mainline in the solution file, so now when I open the project from the development branch, it is actually referring to the project in the Mainline branch.
Please help.
Hisham.
Help... Directory Branching and SCC specific code in solution and project files...
dustinto
Desmond Green
Hello Richard,
The problem seems to be the fact that container files (solution and project files) have references to specific branches on the server.
I did not see that before, but if you bind a project or solution, you can't branch that project or solution anymore.
I am using the MSSCCI plugin, so I am not sure if this is a limitation of the plugin; if you open a solution, no matter what branch it resides on, it will always refer to the parent branch, and any files that you checkout for editing will be checked out from the parent branch.
This behavior defeats the purpose of branching in the first place; I think I will start a new thread for this issue.
Scoob
Two workarounds:
If ProjectA and ProjectB are on the same release cycle, they should probably be in the same branch hierarchy to begin with. With the structure below, for instance, branching the solution will "just work".
$/TeamProject/main/SolutionA/ProjectA
$/TeamProject/main/ProjectB
However, if those projects are being developed by completely separate teams and/or on a totally different release cycle, then you probably don't want them to be part of the same branch hierarchy. In that case, you'll need to split up the solution. (Not ideal, I know, but it seems like that shouldn't be a huge deal if the projects are so different already.) Your build process can still incorporate both of them, of course; the limitation only applies to the IDE.