Branching bound projects and solutions does not work
Hello,
While testing branching capabilities in TFS, I come to realize that for bound projects and solutions, branching does not work as expected.
I hope I am wrong, and if you see any mistake with the following scenario, please tell me.
- Start of with a solution that has two projects
c:\root\solutions\solution.sln
c:\root\projects\projectA.csproj
c:\root\projects\projectB.csproj
- Add the root directory to version control in TFS
$/TeamProject/Mainline/solutions/solution.sln
$/TeamProject/Mainline/projects/projectA.csproj
$/TeamProject/Mainline/projects/projectB.csproj
- Make sure your mapping in the workspace is like so
$/TeamProject/Mainline -> c:\root\
- Open solution in VS 2003
- Select “File” > “Source Control” > “Change Source Control…”and bind project to server
- Close solution
- Open MSSCCI plugin and branch $/TeamProject/Mainline to $/TeamProject/Branches/Ver1
- Create a new mapping in your workspace
$/TeamProject/Branches/Ver1 -> c:\rootDEV\
- Get latest sources from the Branches/Ver1 branch. TFS will put the sources in c:\rootDEV\
- Open solution from c:\rootDEV\solutions\solution.sln, solution will open fine
- Try to modify a file
- Expected result is that the file from $/TeamProject/Branches/Ver1 branch gets checked out.
- Check in the MSSCCI plugin, the file that gets checkout out isfrom $/TeamProject/Mainline branch.
This is a major issue, any input is appreciated.
Thanks.
You are correct that the TFS MSSCCI plugin does not handle branched solutions well. This issue is documented in the Known Issues section of the ReadMe.txt file that ships with the plugin and is due to the fact that the solution's SCC bindings are stored as absolute server paths. The TFS integration in VS 2005 greatly improves the experience with branched solutions by storing relative (to the solution's folder) server paths.
We are currently investigating our options to improve branched solution handling for the next release of the TFS MSSCCI plugin.
In the meantime you may try using Change Source Control to unbind and then rebind your solution and projects so that they pick up the correct mapped path. Another option is to manually edit the bindings to point to the proper server paths.
--Ben Ryan
Hello,
unfortunately Msscci provider does not handle branching (it's known issue). What you need to do, is to modify solution and project file after step 9:
- checkout files using TFS
- open sln and proj files in your favorite text editor
- look for SccProjectName, change its value to the branched server path (e.g. $/TeamProject/Mainline/solutions to $/TeamProject/Branches/Ver1/solutions )
- checkin changes
We hope to fix this issue in the next release.
Thanks
I see that there now is a version 1.1 of the MSSCCI provider. Did this release fixe the problem mentioned in this post?
Regretably, this issue was not fixed for Release 1.1. It is still on our list of issues to investigate for future versions.
--Ben Ryan
Hi Ben,
Integration between TFS and VS2003 without this feature is horrible at best. The main reason my company is looking to convert to TFS from VSS is TFS's ability to do branching. If the middleware piece cannot support branching properly then I am dead in the water. The alternatives given above will not work for me because I have 70+ project files, and there is no way I could manually edit them for each branch and manage all that during the merge process. Do you have any idea of the priority of this feature within microsoft and when it might be available? I cannot imagine how this is not an absolute deal breaker for anyone trying to implement TFS with VS2003. I have worked very hard to convince my company of how great this product is, or promises to be, and I am flat on my butt right now. Thoughts? I just need to be able to figure out a time frame for when I can expect the feature so that I can move forward with the planning of our conversion. I am worried that maybe this is a difficult issue to fix, and that is why it did not make the last release, and may be a year away from being resolved.
Thanks much! I'm not trying to be harsh, I'm just a little desparate right now! I don't want all my work to go to waste.
Scott
Scott,
I can certainly understand where the lack of this functionality could be an adoption blocker. Unfortunately, I cannot answer when the next release of the TFS MSSCCI provider is scheduled as I honestly do not know. I will check with a couple of people in the morning to see if I can get at least a rough timeframe for our next drop.
The handling of branched solutions was a stretch goal for our last drop (i.e. version 1.1) and did not make the cut. As you guessed, this was largely due to the difficulty of solving the issue combined with a very tight schedule. The issue is literally at the top of my list for future fixes and enhancements that Michal and I would like to have in the TFS MSSCCI provider. However, I am not responsible for resource allocation or scheduling for our team and cannot guarantee what the next drop will include.
We (Microsoft) really do want to be responsive to our customers' needs. Most of the functionality in the version 1.1 drop was directly related to customer feedback (e.g. Get Latest on Check Out, Powerbuilder support). Another reason a fix for branching did not make the cut for the last drop was that we had not received much feedback that this issue was a blocker for customers. Therefore you may want to help raise awareness of this issue. Obviously we do read the forum posts, and they help provide visibility. However, if you have a Microsoft sales or support contact, you might consider making them aware that this problem is an adoption blocker for you. I would also recommend posting a comment to Brian Harry's blog (http://blogs.msdn.com/bharry/archive/2006/06/21/641884.aspx) as he has been tracking feedback there. Thank you for your response.
Sincerely,
Ben Ryan
Hi Scott:
Please email tfmsscci@microsoft.com with your feedback. I will respond to your email with more details about the problem. I can tell you right now that due to the fact we do not know what the exact fix is, we cannot committ to a date, but rest assured that it will become our top priority once we start work on the next update to the tfs msscci provider.
thanks
This is a huge problem for my organization as well. I am considering writing a console application that will check out all branched .csproj, .dbp, .vdproj and .sln files and replace the $/TeamProject root with $/TeamProjectBranches. This should do for now but a permanent solution would definitely be welcomed.
I have created a small Windows Forms application called TFS Branched Project Fixer that updates solution and project files created with the MSSCCI provider after branching. It takes the following properties:
- Team Foundation Server instance - The TFS URL or host name to connect to
- Workspace - The locally-accessible workspace to use for local item <-> server item mapping
- Virtual directory suffix - An optional suffix to append to URLs for Web projects contained in solution files
- Original source control path - The hardcoded original source control path contained in the solution and project files.
- Branched source control path - The branch destination for retrieving solution and project files and for replacing the hardcoded original source control path
- Project filter - Semi-colon delimited list of project wildcards
For example, let's say I had a large structure of projects located in $/NathanAlden/Trunk. Some of these are C# class libraries and others are Web projects. On my disk, in C:\TFSProjects\NathanAlden\Trunk, I have a solution file called Widget.sln that references all projects needed to build my Widget Web application in $/NathanAlden/Trunk. Widget.sln will contain direct references such as $/NathanAlden/Trunk/NathanAlden.Common/NathanAlden.Common.csproj. It will also contain a URL for the Widget Web project, for example http://localhost/Widget.
After branching version 1.0 of my Widget Web site from $/NathanAlden/Trunk to $/NathanAlden/Branches/Widget/1.0, I need to update all hardcoded source control paths and I also want to replace the trunk virtual directory name from Widget to Widget_1_0. I want to replace the virtual directory name because I want to be able to host the trunk version and branched versions of my Widget application on the same workstation. Here are my settings for this operation:
- Team Foundation Server instance: TFS
- Workspace: TFS
- Virtual directory suffix: _1_0
- Original source control path: $/NathanAlden/Trunk
- Branched source control path: $/NathanAlden/Branches/Widget/1.0
- Project filter: *.sln;*.csproj;*.dbp;*.vdproj
TFS Branched Project Fixer will find, get, pend edit, modify and optionally checkin all projects matching the project filter in the specified branched source control path.
If Microsoft will give me the opportunity I will upload the application and its source code somewhere so everyone can benefit.
Nate,
We intend to address the MSSCCI provider's branching limitations in an upcoming update to the MSSCCI provider. If you feel your solution will benefit others, then make it available accordingly. You may want to consider putting this out on www.CodePlex.com, Microsoft's community development Web site.
Ed
Is there any ETA on when the updated version of the MSSCCI provider might be available?
Not being able to change the binding location is really starting to hurt us.
Just to add to the chorus, this problem is also affecting VC6, as the MSSCCI/TFS places absolute paths in the dsw/dsp files.
Without a fix, branching is a real pain right now. After branching, all the dsw/dsp files need to be updated before any project is loaded into VC6, otherwise you get the cross-tree confusion in version control.
Thanks for taking this into consideration as you move forward with MSSCCI.
For now, I'll just run this short powershell script from the root of the new branch to update the dsp's/dsw's:
tf checkout /recursive *.dsp
tf checkout /recursive *.dsw
Get-childitem -include *.dsp, *.dsw -recurse | foreach { (get-content $_) -replace <old-root-VC-path>, <new-root-VC-path> | set-content $_ }
Replacing <old-root-VC-path> and <new-root-VC-path respectively. (Please post any better methods than this hack.)
