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.
Related
I have to upload a new project to TFS. This project is already finished but it is not under control version yet.
I have decided to work with two branches: main, dev. In my case release is not necessary, I can do all the stuff using feature isolation branching strategy.
Initially I create a team project. Using team explorer from Visual Studio I create two folders: Main and Dev under team project.
First I upload project to Main folder.
From now on each time a new feature must be implemented I create a dev branch from Main folder and put it under dev folder, let's say dev_branch_01. This dev branch will be short-lived.
The implementation of this feature is divided into parts. Each part is done by a developer so each developer creates a new short-lived branch from the dev_branch_01 just created in order to implement the assigned part. When all developers have completed their part, they merge their dev branch into dev_branch_01 and resolve conflicts.
Once all the parts have been merged into dev_branch_01, QA Team makes the necessary tests against this branch. When all tests are passed by QA Team, dev_branch_01 is merged into Main branch.
Here, I have a doubt: all the short-lived dev branches done from dev_branch_01 by each developer could be deleted? Also dev_branch_01 could be deleted as well?
Later in future, when a new feature must be implemented, we repeat the process again, I mean, we create a new short-lived dev branch from main branch, let's say dev_branch_02 and we repeat the entire process explained above.
We always have one main branch and many short-lived dev branches.
I would like to know if the way we work with main and dev branches is correct.
Lest break this question:
Here, I have a doubt: all the short-lived dev branches done from dev_branch_01 by each developer could be deleted?
In TFS the branch are not physically deleted, when you first delete, TFS will just Hide from the main view, image bellow. because that you can't name a branch 2 times with the same name, to reuse a name you need to force delete which I don't recommend.
So, the answer for your first question the answer is yes, it can be delete without problem, just remember, you can't create a new branch with the same name in the future.
If you want to see deleted branches click in the button Xx in your Source Control Explorer. With this option, you'll see all the history of your old branches which is good because is the kind of think that you don't have with Git ease.
Also dev_branch_01 could be deleted as well?
I don't recommend that for 2 reasons
1 - I understand that you'll want to recreate this branch in the future and like i said, you can't create a branch 2 times with the same name.
2 - With this branch alive you will be able to restore a deleted branch for any reason that you'll find and keep the history consistence between branches.
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.
So I have a TFVC setup that has no Git branches however when I go to link a work item, it only comes up with Git, how do I link work items to TFVC branches? The only documentation I find all uses Git, for everything.
I am trying to have my tasks set up so that when a new task is created, I would create a branch off of Development for that task. However I can't seem to do this as everything is defaulting to Git and it seems like my workspace has no knowledge of the TFVC branches!
Link work item to Branch only support for GIT, it's not supported for TFVC. See Link types showing in the Development section for details.
For Team Foundation version control (TFVC), it lets you link work items to version control changesets or versioned source code files by using the Changeset and Versioned Item link types. When you check in pending changes or use My Work to check in changes, work items are automatically linked to your changes.
So, you can link work item with the link type Changeset or Versioned Item, or create another Git repository, you can use both TFVC and Git in the same project.
UPDATE:
That's a good idea to support TFVC, I have help you submitted the user voice here, you can go and vote it up to achieve it in future.
Currently we have a branch structure like this: Develop --> Release. I want to change it so that it looks like what the TFS Branching Guidance document calls "Basic Branch Plan". It looks like this Develop <-- Main --> Release.
I was going to do this:
Rename Develop to Main (creating Main --> Release)
Creating a branch from this Main reusing the "Develop" name (creating Develop <-- Main --> Release)
Will I have problems with TFS reusing an old branch name for a new branch? Know any gotchas or things to look out for?
Additional Info
I did this in a test instance creating test branches without any files, pending changes, history, etc. (not a good real test) and TFS let me do the rename and branch without difficulty. However, I won't feel comfortable with this unless I can take our production TFS project collection, restore it in the test instance, and test the rename/branch on real data. There is a lot of history and branches there and I don't know what will happen. As noted in the answer, there are other considerations before doing this.
I'm preparing to do similar steps (except I'm moving subfolder locations of both parent and a child while grandchildren stay put.)
QUESTIONS:
When are you planning the rename?
Are there any child branches under Develop branch that you didn't mention?
Do you have any shelvesets against Develop that might be impacted by the rename?
General answer: Proceed with caution. From my reading branch renaming in TFS2010 can cause a few unexpected side effects. TFS will be doing the following steps (under the hood) for your scenario:
Rename Develop to Main ==> Branch Main branch from Develop, then delete Develop branch
Create new "Develop" branch from Main
I recommend reading the following posts:
Renaming Branches in TFS 2010 (ChandruR’s Blog)
"MSDN Blogs > ChandruR's Blog > Renaming branches in TFS 2010
So my recommendations for this case:
Avoid renaming branches - a cleaner solution would be to, at the right point in your release merge all changes to a parent branch and then re-branch to create a new branch hierarchy.
Or for the brave of heart :)
You will need to time the rename of your branch, to a point in your release where you can merge to all related branches. The steps to follow are:
..."
Renaming branches in TFS2010 - But it works on my PC!
“In TFS 2010 behind the scenes a rename is actually a branch and delete process, this meant we ended up with the new branch, but also a deleted branch of the old name. This is not obvious unless you have ‘show deleted items in source control explorer’ enabled…”
"Now implemented as a branch + delete behind the scenes (new name is branched from the old, then the old name is deleted). This allows traceability in History, but allows us to get around the problems with merging renames (see Add, Rename, Add scenario). "
.
RANDOM THOUGHTS
Get all devs to merge (or abandon) all safe changes in child branches of Dev. Also prune any inactive branches before the rename.
Read above articles.
Search to find the page (that I haven't found yet) that describes exactly what will happen in simpler terms based on real experience.
Specifically I'd like to know what happens to shelvesets on the Develop branch after it is renamed to Main. (Next step can answer this.)
You might consider making a "Sandbox" Team Project (or Team Project Collection) then try out your scenario to see if there are major issues.
Pick right timing (see link#1) and go for it.
Check history, do a merge between the renamed branches, check history again.
Allow developers back in.
Good luck, and post back with any new information (including your end results)! -zs
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.