I am very new to TFS. I have below Structure where I have my entire SOLUTION checked into my TFS online Repository.
Now, we are done with this Feature/Version.
What we want to do is...Leave this version AS IS and create a new Version / Branch out of this. This way if we ever have to go back to this version we can easily go back to it.
But Whenever I right Click on Root and Choose "Branch" Then I get an error that "The Bracnh Already Exists". I would like to name the new Branch "Release 2.0" or Something. But I cant Branch out my current Solution.
Creating New Folder option is Disabled.
Why is it disabled? I have full access to TFS/
You can't branch from the team project root. Reorganize everything to be in a trunk folder (TFVC convention is main, but you can call it whatever you want), and branch off of that.
For what it's worth, branches shouldn't be infinitely branching -- you should branch off of a trunk to do development, then merge back in when development is done. There are numerous reasons why this is the case, but I suggest doing some reading on TFVC branching strategies to find one that's appropriate for your organization.
Another developer has some test files in a new directory in their branch. They're useful to me as well but I'm working in a totally independent, newer branch and he's not likely to merge his branch anytime soon.
I am able to branch his "test-data" directory into my branch but I really want to break the branch association so they're treated as new files in my branch, i.e. so TFS thinks our branches independently added the same new files and we resolve conflicts later since our test data is likely to diverge.
Is there a way to "orphan" the branched files somehow?
You can just get files in TFS using the web access component. Just browse to the folder through the code portion of web access and right click > get as zip.
You can do it from the command line as well but I am not familiar with that. SO has a lot of resources on how to do that from what I have seen.
It is possible to break the branching relationship in TFS and there are many questions on SO on how to do that. But your branch wouldn't initially treat them as 'added' and the history will be in TFS. I would recommend branching just the folder his useful code into your branch and leaving that relationship for posterities sake.
That being said, depending on your situation it may not make sense. If you want to remove the branching relationship immediately, then I don't think you need to use TFS.
I have an environment where I'm building several library solutions in TFS. At the end of the build process the script packages them into a NuGet package and pushes them to our local feed.
Now we can include these libraries, which change little day-to-day, in our upstream projects.
These libraries as well as our upstream projects generally are branched at the same version. Basically the trunk is our evolving latest version. Say before branching the trunk is 3.0.0.123, 123 being a running build number. At some point we mark the current trunk as what we're going to release and branch it. The version number of the trunk at the time of the branch becomes the version of that branch and we would increment the version in whatever appropriate manner for the trunk to what we would feel is likely going to be the next release (say 3.1.0.456).
This presents a slight oddity to how we'd like to use NuGet. We would want that the branch, 3.0.0.456, use the lateset library from the branch (perhaps 3.0.0.457) and the trunk to use the latest from the trunk (3.1.0.789)
So what this basically boils down to is can we setup the versions for a solution using NuGet to be similar to the manner NuGet uses when defining dependencies within a package?
Ideally, I'd like to tell the branched upstream application to use [3.0.0.456, 3.1) and the trunk to use latest (no version). In this scenario it would pick up the branch would pick up the next branch build (3.0.0.457) and the trunk would pick up whatever the last NuGet package that was published to the feed.
The only idea that I've come up with as a possible solution is using parameters for the build template and using that to update the package.config file before the NuGet targets are run.
I appologize if this should go on SuperUser or elsewhere...
After doing some digging to have my build do some auto creation of packages for our library projects I came to the (wrong) conclusion that this was a limitation of NuGet. I parsed their source for any XSD documents to describe their XML so that I could see how their nuspec worked.
While I had their source I started looking into how I could modify the package.config file to accept their schema for limiting versions. After some digging I found an attribute that can be added to the package node in package.config: allowedVersions. This is exactly what I was looking to add!
Once I had this piece of information I was able to dig a little deeper into how it was implemented. Turns out that this functionality has been around for a while and is even documented on their docs site: http://docs.nuget.org/docs/reference/versioning
It is in the dependency versioning guide located at the bottom. I must have completely glossed over it or never read that far!
Turns out that this was a non-issue and the only problem was my ignorance. Just a reference for any Googler's out there that land on this page!
SOURCE (LOCATED AT BOTTOM OF PAGE): NuGet Versioning
We are using TFS Continuous Development model
Main Trunk
-> Various Development branches
-> Various Release branches
All merging back to main trunk
Now we need some major changes to our folder structure and solutions
How do you handle folder restructure in above model of TFS usage?
do i need to draw line and create new structure from latest Main trunk and lock all branches and do updates then creates branches with restructured new trunk.
Or am i underestimating TFS, would be able to handle major folder structure updates and propagate over to branches. As long as i know if we move around folders in branch or trunk it don't like it.
TFS can handle this, and does it by "renaming" each file by changing it's TFS location path.
I've been able to do this in a child branch, merging it up into the trunk, and then back into another branch.
It does get a little tricky, and you are sometimes presented with confusing dialog boxes because it can't automatically resolve renaming changes.
When I got this box, I resolved any actual content changes in files. I was then able to cancel out of manually resolving every renaming change without any problems, and everything worked perfectly.
We have a TFS 2008 project with two branches ("Main" and "NewFeature").
Each is a complete, independent "copy" (variant) of the source code.
By changing the workspace mappings, we can map either variant onto our local PCs and have been working with both branches with no problems.
However, if I set up the mappings to switch our build server on to the NewFeature branch (which should simply swap in the NewFeature source code without changing anything else as far as the build server is concerned) I get errors:
There is no working folder mapping for $/Main/Product.sln
i.e. when it is building from the NewFeature branch, something is still looking in the Main branch, even though there are no references anywhere in the source code to this branch. It appears to be caching some reference to Main?!
I have done a completely clean build (deleted the build folder from the server and run the build with /p:ForceGet=true to make sure the mapping is flushed through to the server, and there are no files on the server that might cache the workspace bindings), but this doesn't help.
Any suggestions?
Verify that:
$(SolutionToBuild) uses a relative path when referencing Product.sln
the relative path between $/NewFeature/.../TFSBuild.proj and $/NewFeature/Product.sln is the same as it is in the Main branch.
/ EDIT /
Note, however, it's not important that $/Main and $/Branches/Feature live at the same level in the tree hierarchy. Nor should the local path on the build server matter.* All that matters is what's underneath each branch. If the contents is internally consistent then all of your existing build scripts should work without modification.
For concrete examples of how I like to tie everything together, see my past answers, e.g.:
Modular TeamBuilds
SDLC Mangement for TFS Build Scripts
Where to put my database project in TFS?
How do you share external dependencies between Visual Studio solutions?
My way is not the only way, but I can attest that it works better than all the other variations I've encountered over the years :)
*Frankly, trying to micromanage Team Build can become a lot more painful than the proposed restructuring to your MSBuild scripts. For reliability you have to place your tfsbuildservice.exe.config customizations under version control somewhere...if you own >1 build server (or might in the future) then you have to consider a change deployment strategy...you end up needing a meta-SCM process to manage your SCM process!
I also had this problem when running a build from a branch in TFS 2010. TFS was reporting that "There is no working folder mapping for $/Main/Product.sln" The solution turned out to be to edit the build definition as follows (I am using the "Default Template" build process template—I have not tried this with a custom template):
Go to the Process section/tab of the build definition.
Expand 1. Required and look for Projects to Build. Make sure this entry is pointing to the solution file inside the branch you are building.
Expand 2. Basic and look for Automated Tests. Point this to the correct test settings file in the branch being built.
OK, the results are in - I've found a workaround.
Due to our legacy build processes (build, copy, obfuscate, build custom installers, copy to drop folder), I can't easily place the branch alongside the main branch. It needs to replace it.
So, if I have Main and NewFeature, I wish to unmap Main and map NewFeature in its place (i.e. use "c:\Main" on the build server, and simply change the source code that appears there)
Solution #1 (the most simple, obvious and logical solution) is to use these mappings:
$/NewFeature -> c:\Main
Expected result: NewFeature code structure simply replaces Main, and the build server doesn't know it's on a different branch.
Actual Result: Failure with a "you haven't mapped $/Main even though you're not using it" error.
Solution #2 is to do this:
$/Main -> c:\IgnoreThisFolder
$/NewFeature -> c:\Main
This works (it suppresses the warning and thus allows the build to proceed with MSBuild unaware that it is building in a branch). However, it's ugly and the build gets all the Main branch source code unnecessarily.
Solution #3 (untested, too expensive to try unless I know it'll work much better than #2) is:
Move all the source code (from $/Main, $/Branches/Feature) to $/Branches/Main and $/Branches/Feature to get a consistent hierarchy depth, and rewrite the MSBuild script to work with these new paths.
Hope that I can then map in only the branch I need and edit TFSBuild.proj to redirect it to build in that branch.
(Edit: Yes, this works well. We have now reorganised our entire code structure so that everything (all branches) is under a common root in a single Team Project, and branching/building is no longer a problem - it's easy to do whatever we need now. The trick is to insert a root folder into the hierarchy so that you can branch at any level you like. I've added a small tweak to the build script so that we can pass the branch to build as a parameter to MSBuild, so it's easy to build any variant now. Any branches we don't want to work on can just be cloaked and the build server remains happy.)
Summary
All these solutions (to use the technical term) suck. You have to remap the workspace (in this case, it's not simple: 9 mapping entries are required so it's an error prone and tedious thing to do), edit the TFSBuild.proj, delete all the source code, and run a build with /p:ForceGet=true to switch the build between branches. So it takes about an hour to switch branches. Unbelievable - it should take a few minutes at most!
I realise our project is far from ideally set up, but I can't believe it should be this difficult to branch in TFS (It was a piece of cake in SourceSafe, Accurev, and Perforce, so why so painful in TFS?).
How does everyone else organise their TFS branches? How do you switch developers between branches? How do you switch server builds between branches? Does it really have to be this painful?
When you Edit the build definition there are two places that need to be changed.
Source Settings - Point to your new project location
Process - (This sometimes takes a while to load so be patient) Under Required, change the "items to build" location to the new solution.
Hope this helps.
New update:
As reported in the other answer, I found a workaround that was ok for a short-lived feature branch, but it really didn't work very well. I've since come back to the problem, and the full solution is ridiculously simple:
In the TFSBuild.proj, the path was based on $(BuildProjectFolderPath). This path resolves to a server-side (source control path) like $/Main - not a local path (D:\ServerBuildFolder\Main).
Unfortunately, for historical reasons our source code is split across several team projects, which means the one "branch" is fragmented into several branched folders in Source Control (i.e. $/Main/Code and $/Libraries/Code. You can't create a branch that contains $/Main and $/Libraries). We thus have to reassemble these disparate fragments from Source Control back into a coherent hierarchy using workspace mappings.
This means that Richard was spot on - the relative path from the TFSBuild.proj file to the .sln file was incorrect, because MSBuild/TFS is assuming that the .sln lies within the same Team Project and source control hierarchy (so was looking for $/Main/Libraries.sln instead of $/Libraries/Libraries.sln).
The solution is simple: I replaced $(BuildProjectFolderPath) with a local path (e.g. D:\ServerBuildFolder\Main) for the files, so that the relative reference was resolved in "local space" (after the mappings had been applied), and MSBuild is now running sweetly.
The moral of the story:
1) NEVER use more than one Team Project if there is any chance that you will ever wish to have any kind of reference between those code-bases. Don't be fooled into thinking that a new Team Project will offer some kind of painless logical distinction between applications/libraries. Extra projects have proven to just be an administration nightmare - loads of extra problems for absolutely zero benefit. (It's all one big shared pile under the bonnet, so all the work items and source control folders are still visible in all the projects (!), but it adds a few brick walls that make inter-project links very problematic)
2) Always create a single root-level folder in your Team Project source control, and then put everything else underneath that folder. e.g. For the project "$/Main", create "$/Main/Root" and then put everything from your source hierarchy inside Root.
By following these rules, you will be able to branch the single 'Root' folder in future, and will then only need a single branch and a single extra workspace mapping. This will help you avoid premature baldness.
(In my defence, I would have done it this way to begin with - I'm working with a legacy setup. In defence of the legacy setup, it sounds good on paper but just isn't a Microsoft-supported approach!)
I got this error and all I can fathom is that the definition became corrupt or something. I just redid the process stuff (re-added the solution I was trying to build) and remapped the workspaces and it started working again. HTH.