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.
Related
We are using TFS 2010.
In 2 branches I have file that is clearly different in each branch. When I compare branches this file is displayed as different, but reconcile option is grayed out. If I try to merge, I get message that there is nothing to merge. Can somebody please shed some light here? Thanks.
For those willing to read more, here is the scenario I am facing often and I don't know how to deal with it:
There are 4 branches:
- Main branch
- Release branch (child of main branch)
- Developer1 branch (child of release branch)
- Developer2 branch (child of release branch)
Developer1 and Developer2 made changes in their branches and merged code to Release branch. In meantime, changes were done in Main branch (Urgent Fix or whatever). When changes are deployed, I made attempt to merge code to Release branch. Merging proved to be difficult as there were too many code conflicts at this point. So I made decision to take source branch (main) when resolving differences (that removed all changes made by Developer1 and Developer2 from Release branch). Now, I would like to ask Developer1 and Developer2 to merge their changes again and resolve their own conflicts. But, they can't merge, nor reconcile.
After you compare a server folder and a local folder, you can reconcile the differences between the folder contents and between files that have conflicting pending changes in your local folder.
You should also meet below required permissions
To perform these procedures, you must have the Read and Check out
permissions set to Allow. For more information, see Permissions and
groups reference.
More details take a look at this official tutorial--Reconcile differences between two folders
A step by step process show hot to use reconcile command, you could take a look at this reply here: How to have TFS 2010 detect changes done to files outside of Visual Studio?
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 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.
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".
We have 3 environments: dev, test, and staging.
I want to check in and out of TFS. When we make changes, I want to promote the code to the dev web server. Next I want to promote the changes to test, then to staging. Would it be possible to do this with Team Foundation Server?
Why on earth are people suggesting branching? You branch for different features or static branches for release snapshots.
Surely the differences between these environments are configuration items/files and settings within these. All you need to do is get your deployment and release management process in order.
Create appropriate MSBuild tasks and use TFSBuild (Continuous Integration) to call these to take care of outputting the correct config files for the Environment/Configuration you are building. You can trivially add another MSBuild target that deals with the appropriate deployment to the respective target environments.
You can manually checkout the code from each branch, make your changes subsequently to each branch, and checkin. Very carefully.
Much better is to have these 3 environments be branches of each other. (Typically you start with dev, and branch to the other 2 in turn). Then you can use the Merge functionality to merge (for example) your dev changesets directly to test, etc. At this point your Test modules (that need to be changed to match dev) are checked out, with the changes. Then simply commit the changes. Then repeat for staging and rinse. This is the suggested methodology for this common scenerio.
Two important notes:
Even though TFS if very server-centric (compared to SVN, for example), this merging functionality happens on the client. You need to have each branch mapped to your machine. After the Merge process is completed, you'll have uncommitted changes in the target branch until you check in.
In Microsoft's vision and in the example I give here, these branches are permanent. This was a change from my previous practice using SVN, where whole branches were created/promoted/retired all the time. In the TFS way, you create the Test branch and it remains, indefinately, the Test branch. It's never promoted; its changes are merged elsewhere.
Building is a separate action. You need to set up a separate build for each situation, though of course once you set up the first one the other two will be trivial. After your merge to staging, you'll then run the staging build. (From Team Explorer or in the Build menu). TFS is a bit heavy but once it is set up it does handle this situation very well, easy for a distributed team to merge and build quickly (with automated build tests, etc.).
Yes, this is possible, but you must manually check them in from one branch to another.