We have release branches that are branches off of main.
We also have experimental branches that are branched off of main.
We now have a feature in one experimental branch that we want to add to another experimental branch.
The problem is that we don't want to merge those changes into main yet because then it would go out in a release sooner than planned.
What is the best way to accomplish this? Baseless merge? Should experimental branches not be merged off of main?
If you only worried about the planned release, you could use labels as a workaround. The difference between label and release branch you can refer this question：In TFS, should I label or create a branch for a production release?
As for should experimental branches be merged off of main or not, it's based on the useage of your experimental branch. If you branched what you needed from the main branch into an experimental branch. After some changes on experimental branch, you want to apply the changes to main, then you should merge back into main. If you fininshed the work and will work on another one, then you don't have to merge off of main and you could orphan this branch or delete it.
If you really want to perform this type of merge you can through something called a baseless merge. You could run it in UI with VS2012 and up or runs from the tfs command prompt:
Tf merge /baseless <<source path>> <<target path>> /recursive
Related
I have created a branched copy of my main production code-base so that I can safely perform development.
This involved creating a Main branch (the parent) and then another branch on the same level for my development called Dev(the child).
I have managed the merge the content from my child branch to my parent branch.
However, when I try and merge from my parent branch to my non-branched Production code base, I encounter problems.
I have attempted peforming a baseless merge using the Developer Command Prompt for Visual Studio 2017 Professional edition.
Do I need to do anything else such as converting my Production Code base to a branch. Then to re-parent the main branch and choose the new Production Code base branch as a parent, and perform the remaining merge that way ?
Is that the best way to accomplish my final merge ?
First, if your Production Code base are still folders not a branch. You should convert them to a branch first.
In TFVC, you could only merge to directly related branches(parent or child). There is no merge relationship between main branch and new Production Code branch in your case . You have to perform a baseless merge through tf merge command.
tf merge /baseless <<source path>> <<target path>> /recursive
/baseless
Performs a merge without a base version. That is, allows the user to
merge files and folders that do not have a merge relationship. After a
baseless merge, a merge relationship exists, and future merges do not
have to be baseless.
Note Baseless merges cannot delete files in the target. You can manually carry over such changes.
If you want to reparent to other branch, you must set a relation ship between the 2 branches first.
In other words, you still need a baseless merge first. Afraid, we could not take away the need for a baseless merge. As for how to reparent branch in TFVC, you could refer my answer in this link: TFS reparent to be a grandchild
Background
If I merge our main branch to our development branch, TFS will state that there are no changes to commit. And yet, a file level comparison (using WinMerge) clearly shows that there are differences (e.g. files missing, files with different content, etc.).
In short, our main and development branches are no longer in sync which is most likely due to changesets that were lost during previous TFS migrations.
Question
What is the best way to produce the following?
Synchronizing the main and development branches by: performing all of the necessary insert/update/delete operations on the development branch. (i.e. main is the master copy).
At the end of the process WinMerge should indicate that there are zero (0) differences between the two branches.
Keeping the development branch history intact.
Notifying TFS that the development branch is now fully synchronized with main so that:
TFS won't try to merge older development changesets with main
only future changes to development will be pushed to main during a merge operation.
TFS is not my area of expertise - any guidance that you can provide would be greatly appreciated.
Context
Visual Studio 2015
TFS (version 14.95.25122)
References
Merge Command
"Performs a merge without a base version. That is, allows the user to merge files and folders that do not have a merge relationship. After a baseless merge, a merge relationship exists, and future merges do not have to be baseless."
Although Development was branched from Main, it looks like this might address my lack of history (i.e. missing changesets) problem.
TFS Merge: Best Practices
TFS: Overwrite a branch with another
tf merge A B -r -force -version:T
I don't think this will work for us because changesets are missing.
When TFS does a merge, it bases the merge on prior merge history, not on the actual contents of the source and target files.
This issue may by caused by picking keep target when perform merge or at one time, a merge with the discard option performed (using the command line TF merge /discard).
To solve this issue, you can try to:
Use the /force option with the tf merge command. If there is a changeset that was previously merged (perhaps incorrectly) and you want to merge it again. The /force flag ignores merge history that indicates a particular changeset was previously merged from source to target, and merges the changeset again.
Undo the previous merge using Rollback. If you've recently done the merge in which changesets have been discarded. Find it in the history, rightclick the changeset and pick Rollback and check in the code that has been undone.
I have the Development branch forked from the Main branch.
Could I merge the Development branch back to the Main so that Main branch code would be equal the Development branch?
What is the most safe and reliable solution for this?
The easiest way I've found to do this is to do a merge using Visual Studio and the Source Control Explorer.
In the Source Control Explorer, right-click on your development branch and select Branching and Merging > Merge
In the Target Branch drop-down select your trunk ("Main") as the destination. This is likely the default selection if you've branched from Main originally.
There are two options:
All changes up to a specific versions: You choose based on a revision and merge it all up to that revision in one fell swoop. If you have a lot of changes, this can save you some time, but also is riskier in terms of resolving conflicts if there have been a lot of changes in Main.
Selected changesets: You select single or groups of changesets to merge back and then repeat this process until you've merged back what you need. Less risky option, but much more time consuming. I personally prefer this approach so that I can see the changes going back into the trunk and know what to expect as changes.
TFS will instruct you if there are merge conflicts while you are merging. This occurs when you change something in the trunk after you've branched to your development. If one of the changes you've made in development conflict with the changes you've made in the trunk, you will have the chance to resolve this in Visual Studio.
If you do not have any conflicts, your development changes will move into the Trunk and simply merge with the changes you already have there.
I admit one work place they merged the Trunk to the Branches, but its not supposed to work that way.
The generally accepted method is merge the Branch back into the Trunk.
It sounds like you are working in the Trunk ("I can create some additional folder or additional files in the trunk") and wanting to merge into the Branch.
I recommend doing it the standard way: only work in Branches merging back to the Trunk, never coding directly in the Trunk.
So I fixed a bug on our main branch some months back, let's say some old changeset 555. Recently, I manually copied these changes to a child branch for a recently approved hotfix, changeset 999. I would like to do a Track Changeset on 999 and see this it has been merged to main as 555. But, I've done this backwards according to the TFS rules, you can't merge down to a child branch.
Is there a way to tell TFS "accept my old changeset 555 as the merge of 999 to the main branch"?
This is analogous to the ClearCase version tree workflow, using the "don't perform merge, just draw arrow". Thus the Track Changeset for either 555 or 999 would show that they are related.
I'm not sure what you mean by
But, I've done this backwards according to the TFS rules, you can't merge down to a child branch.
There shouldn't be anything preventing you merging this change to a child branch, you might have some merge conflicts to resolve. However if that really isn't a possibility and you want to merge "999" in to the main branch without actually merging the code (i.e. adjust the merge history) then you can using the tf merge command line.
Open a visual studio command prompt and use the command
tf merge $/TeamProject/childBranch $/TeamProject/MainBranch /version:C999~C999 /recursive /discard
This will tell TFS to update its history to say that the merge occured even though it hasn't. You might want to use the /preview switch before you do the merge "for real" to make sure you are discarding the files you expect.
I've the following structure on TFS:
$Base
- $Dev Branch 1
- $Integration Branch 2
I would like to merge the changes on Dev Branch 1 to Integration Branch 2 so that build guys can kickoff Hudson build of this Integration Branch.
I'm using Visual Studio 2008 Team, and when I try to merch Dev Branch1 I can only see Base on Target Branch drop down.
Could anyone please advise how and if it's possible to merge between Dev and Integration branches above.
Thanks
There are a couple of ways to do this but neither are that great. For the first method you will need to install the TFS 2010 power tools
Use a shelve set. Start the merge from dev to base, resolve any conflicts. Do not check in the merge, instead shelve the changes. Then from the command line use tfpt unshelve "my shelve set" /migrate /source:$/teamProject/dev /target:$/teamProject/integration. This will migrate the shelved changes to the integration branch without having to commit the changes to the base branch.
Perform a baseless merge between dev and integration. You can do this by using the command tf merge $/teamProject/dev $/teamProject/integration /baseless /recursive once the baseless merge has established a branching relationship then you can do further merges through the UI. Be warned though that a baseless merge won't know about any files or folders that have been renamed or moved so you will need to make sure you take this in to account.
Personally I'd go for option 1 if it's a one time thing. If it's going to be something you think you'll need to do regularly then I'd do the baseless merge when all 3 branches are in sync I.e. just after you've merged from dev to base to integration. This should minimise any issues with the baseless merge.
You might also want to take a look at your branching strategy so that you don't need to perform complex merging operations very often. If you use an integration branch then it should have a direct relationship with any branches you need to integrate. Check out the ALM rangers branching guidance.
You can only merge to where the branch was created from. You would have to merge from Dev to Base and then again from Base to Integration.
If you want to merge from Dev to Integration directly then your Integration branch should be created as a branch from Dev not Base.