We have a project that is in TFS 2010 and was incorrectly branched. We want to fix it.
This is the current structure we have:
Development
Integration
Main
The problem is that Main is a branch of Integration, which in turn is branch of Development,
when it should be the very opposite.
In other words, first it was created Development, then branched Integration and then Main.
Now all three branches have same code (were merged).
So, Is it possible to fix the TFS references to have the right flow: Main -> Integration -> Development?
As far as I know, there is no way to make this change behind the scenes. The problem you have in hand is that the Development and Main branches are out of place. Easiest thing to fix this would be to rename the "Development" branch as "Main" and vice-versa or Use the REPARENT option as shown at the end of the answer.
Am assuming that in your case since you have only one DEV branch (it wouldnt be possible to have more than 1 dev with the current branching structure), the development for the next release wont happen till the current release is out in production right? In that case, you can wait till the end of the current release and then rename the branches, so that all the 3 branches are in sync before the rename.
(Keep in mind that "Rename" changeset would affect all the files and
folders in your branch, and from the comments below I can understand
that it can be very problematic if you do it at the wrong time. Choose
your time very wisely, make sure that you dont have any changes
pending between the branches and it's just the "Rename" changeset
thats pending between branches)
Another approach would be to use REPARENT.
After a great discussion in the comments below, I tried the options myself and the best way to fix this would be to use the "Reparent" option. I tried this out myself by creating three different branches. You can do the following to fix it:
In Visual Studio, Click on the Main branch -> then File -> Source Control -> Branching and Merging -> Reparent. Select "No Parent" and then click "Reparent"
Click on the INT branch -> then File -> Source Control -> Branching and Merging -> Reparent. Select "Main" and then click "Reparent".
Click on the DEV branch -> then File -> Source Control -> Branching and Merging -> Reparent. Select "INT" and then click "Reparent".
Related
I started using TFS and I was not using branches for my project, but now I need to manage releases, so my Idea is to make Branch from the project and for every release create new branch from the main branch.. so
In VS2015 Source Control Explorer, i click on TFS project > Branching and Marging > Convert To Branch and this error happened
TF203028: You cannot create a branch at $/ProjectA because a branch alreadyexists at $/ProjectA/Main. If $/ProjectA/Main is not a branch convert it back to a folder and retry the operation.
the problem is that I don't see any branches in source control manager neither in TFS website, I created empty branch earlier but I deleted it. What to do ? I don't want to create new project with Main branch and copy/paste the source codes because I want to preserve the commits.
In TFS, you never really delete anything. In fact, if you look under Tools -> Options -> Source Control -> Team Foundation Server, there is an option to show deleted items:
To actually delete an item, have a look at the tf destroy command.
I believe that you can simple rename the folder, and that will maintain your history, should you not wish to permanently delete the old branch.
We have 3 TFS branches – dev, test, and prod.
TFS works well for us as source control as long as we check in and get latest often. Then the merging is small and we can resolve any issues right away. We know that if we don’t do this every day, then merging our code will be painful.
But by the time we are ready to promote to one of the other branches, there are huge changes in the code. We don’t want to keep any of the code in the target branch, and we really do want an exact copy of the source version, not a merge.
We do like having the 3 branches so that change sets are kept for the complete set of changes in each deployment/promotion.
I don’t see a way in TFS to do this very common function. I have been using two workarounds:
If only one user does the merging from one branch to the next, TFS really does copy all changes. But it does not work if the user is different than the last user attempting the promotion, then TFS will merge the code.
I have checked out the whole solution of my local copy of the target branch. Then done a file system copy of the source branch folder into the target branch folder. Then checked in the solution.
Is there a right way?
The correct way to merge is:-
Set up a shared workspace that contains both branches (if you don't already have one)
Get the latest Target branch code
Get the latest Source branch code
Merge from your Source to your Target using Latest Version and All Changes to a Specific Version
Submit your Changes to Source
To overwrite the target if you get conflicts, to ensure that the target is definately overwritten, Select Choose Source version at the conflict window
I know this post is way late, but
My solution in this scenario
Prod -> Dev -> Test
(parent) -> (child) -> (grandchild)
When test is ready to be promoted, I do the following.
Delete Prod (This can be undone with rollback, but check-in)
Branch Test -> Prod (Use the same name a location as the old deleted version), so your new branch structure will be Dev -> Test -> Prod
Reparent Prod (new branch) to "none"
Reparent Dev to Prod
Delete Test
Branch Dev -> Test
When you look at the new branch hierarchy it will look the same as when you started but the code in prod will be the same as Test.
We have a TFS branch structure like Main > Integration > Several Branches under this.
The problem is that I created a folder 'feat-IIS6toIIS7Migration'outside the above hierarchy when I started coding. After finishing coding I converted the folder to a branch.
But the new branch has no parent and I want to put it under Integration. It seems that its impossible to do this in TFS, since when I try to re-parent I get an empty list of possible parents. Is there a way to put the new branch under Integration?
If you want the folder to appear under the integration branch then you can just move it (right click in Source Control explorer and select move).
$/Root/Integration
$/Root/feat-IIS6toIIS7Migration
becomes
$/Root/Integration/feat-IIS6toIIS7Migration
When the integration branch gets merged with either main or your development branches the folder will be added to those branches as part of the merge.
If you want to give the feat-IIS6toIIS7Migration folder a branching relationship with integration then you need to perform a baseless merge. Note you should only do this if the feat-IIS6toIIS7Migration folder is a full replication of the integration branch.
In TFS / VS 2012 you can perform a baseless merge from the GUI.
Right click on the integration branch in Source control explorer and
select merge. This will be your source branch.
In the target branch dropdown you won't be able to see the
feat-IIS6toIIS7Migration folder.
Select "Browse" and then navigate to the location of the
'feat-IIS6toIIS7Migration' folder.
Keep hitting next until VS performs the merge.
I would expect there to be a fair few merge conflicts and you'll need to resolve a lot of them manually.
In the future it would be better to create the branch for your development before you start work, then you can take regular merges so you don't have a big merge at the end of your development.
So, we have our main dev line, I create a branch, and developer b creates a branch. We both do some work. developer b finishes his work, merges back into the main dev line. I know his changes will affect me, and rather than deal with the conflicts later, I would like to update my branch, with the changes that are now in the main dev line, so I can deal with them in my branch, prior to merging back into main.
How do I do that?
From Visual Studio, open Source Control Explorer:
View | Team Explorer
Select your Team Project from Team Explorer, expand it, and double click Source Control
In the left-hand pane of Source Control Explorer, select your Team Project.
In the right-hand pane, find your mainline branch, right-click and select Merge...
In the Target branch drop-down, select your dev branch.
If you want a subset of all the changes in the mainline:
Choose the Selected changesets radio button, click Next.
Select the changesets that represent the merge from your other dev's branch into main, click Next.
Otherwise, keep All changes up to a specific version selected, click Next
The next step has you pick a Version type. The default, Latest Version is obviously straightforward and self-explanatory: you would be brining all changes since your branch was created from the mainline down into your branch. The other choices are straightforward, but a tutorial explanation of each option available here would take a fair amount of space.
Walk through the remaining steps of the wizard.
Click Finish.
If there are any errors or merge conflicts, you will be prompted to resolve them, similar to what you would see if checking your changes into source control when other changes had been made since last checkout.
After the merge is done, all the changes are in your local copy of the branch, but they are not yet committed to source control. Once you've completed all your builds and testing on your branch, you can check in the merge. From Visual Studio:
View | Other WIndows | Pending Changes
Make sure all the files related to this merge are checked, add comments describing the merge, and click Check In.
I recommend keeping merges (and any necessary merge conflict resolution, build breaks, test breaks) as their own changeset. That is, do not mix other feature work with merges. Granular changesets make it much easier to review source control history, and to identify a single change of interest. Keeping merge work in its own changeset helps work toward that goal.
There is command-line for merging as well, run tf merge /? from a Visual Studio Command Prompt.
In TFS, what is the best way to mark dead branches? Do you move your branch? Branch release it? Delete it? Rename it? What problems have you run into for each of these approaches? What are the good points?
It would be nice if there were a simple interface solution that would simply mark or filter the current view if a particular branch was tagged as dead. That way you wouldn't have to do something permanent like rename or delete a branch . . .
Deletion isn't permanent, so I'd go with this option.
You can then opt whether or not to view deleted items in SCE (Tools -> Options -> Source Control -> Visual Studio Team Foundation Server -> Show deleted items in the Source Control Explorer).
And you can choose to undelete the branches if necessary.
After merging back to the trunk we do delete them much easier than having to cloak them in workspaces, see Ian's about deletes not being permanent.
We move our dead branches to an archive area of the project.
Because the branches are cheap in
TFS, there is not a space concern.
Deletion can cause bizarre problems when someone attempts to add something new with the same name.
Moving them enables continued use of features like Annotate (a.k.a. blame), which allows drilling through branches to see a full history of changes.