Suppose I create an experimental branch in TFS. Now, I am finished with the branch, and I want to keep it around, but it has diverged sufficiently from the source branch that I want to make sure that no one can merge it back on accident. Is there a command in TFS to sever a branch, so that there is no merge path back?
I'm not sure if this will prevent a merge but in TFS 2010 you can turn a branch in to a folder
Check out Buck Hodges blog on the subject
As far as I know, you can set permissions on a branch.
Related
My team's policy is to not check in broken code into TFS. But what if two team members are working on the same file and each member's work represents a partial solution ? One members changes won't work without the other.
How is the best way to combine the code and still follow policy of not checking in broken code ?
Both developers could create a shelveset of their changes once their own coding is complete. Once it's time to merge their code, you have 1 developer unshelve the other developer's shelveset into their own workspace. Doing this will also trigger the Merge Tool in case there are any merge conflicts that can't be automatically resolved. This should allow the developer to combine work with the other without checking in broken code.
Note that both developers should make a shevleset of their own work before unshelving the other's, in case the unshelve of the other developers work goes terribly wrong in the merge and they need to revert their own work to the un-merged state.
Here's some documentation on creating and unshelving shelvesets
Consider allowing broken code on branches. The team members could commit code to branches and merge those branches together before merging into master. Your primary or master branch should require a passing build before a pull request can be merged in.
Look at the feature branch model: https://learn.microsoft.com/en-us/vsts/git/concepts/git-branching-guidance. This does not depend on Git but it is convenient as branching is cheap.
Both developers work on the feature branch which is allowed to be broken. When they are finished they issue a pull request to the master branch. The merge is only allowed if all tests pass to make sure the master branch stays healthy.
I recently introduced TFS to a project team that had not been using version control. Our structure is pretty simple:
MAIN branch for production-ready code
DEV branch for (complete) test-ready code
Feature branches for incomplete code not ready for testing
As I said, this team is not used to using version control. Over the holidays a well-motivated team member decided he would try to work on a feature, however he did this directly in DEV and made a number of check-ins. His feature is not complete so I don't want it polluting DEV for now, but I don't want to lose the history of changesets.
The obvious way is to make a new branch off the last changeset before his feature, merge the rest to the new branch, and rollback DEV. However, I'm afraid I'll lose the history of changes and be left with just a single "merge" changeset in the new branch.
If this is the case, is there a way to simply move all the changesets after a certain changeset into a new branch and keep the history?
EDIT: Basically I want to turn this:
DEV ---(1)--(2)--(3)--(4)--(5)--(6)--
into this:
DEV ---(1)--(2)--(3)----------------
\
NEW (4)--(5)--(6)--
This is not supported in TFVC ( nor any other SVCS). If you were using Git is TFS there would be hope, but not here. Your suggested solution is your only avenue.
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.
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.
Here is my current setup. (TFS2008)
I have a TRUNK with latest.
I have BRANCH-A off of TRUNK with only the production ready code merged in.
I would like to create a new BRANCH-B off of TRUNK but I don't want all the latest code, I only want what is currently in BRANCH-A.
After this is done I will be merging into both BRANCH-A and BRANCH-B from the TRUNK (so I don't want to branch BRANCH-B off of BRANCH-A.)
Thanks.
You need to perform a baseless merge. This sibling situation that you want to achieve is exactly what is described in How To: Perform a Baseless Merge in Visual Studio Team Foundation Server:
The process of merging items that are not directly branched from each
other is called a baseless merge. For example, you might want to merge
a change between two release branches, which are siblings of each
other, without merging up to the parent branch. You can only perform a
baseless merge by using the Tf merge command. You cannot perform a
baseless merge from within the Visual Studio IDE.
When you perform a baseless merge, TFS does not have any information
about the relationship of the files in the branches. For example, if
you have renamed a file, this will be viewed as a deleted file and a
new file will be added in the branch. For this reason you have to
perform more manual conflict resolutions than when you perform a
normal merge. However, you only have to perform this conflict
resolution once. After you have performed the baseless merge, TFS
records merge history and establishes a relationship between the
folders and files.
When you create BRANCH-B, you can either choose latest or a specific date/changeset/label. Take a look when you created BRANCH-A and create the BRANCH-B from the same date/changeset/label. As long as you haven't made any changes to BRANCH-A, you can create B to match.
Also, if you haven't already, take a look at the TFS 2008 Branching guidance. There is some great information and uses a pragmatic approach.
For TRUNK
On Create Branch you have option as a "Branch from Version" - by default By Latest Version is selected.
Select By changeSet or By Date