I want to create a new stream in TFS just like we use to do in clear case or clear quest tool by IBM. I believe we can achieve the same thing by creating a branch. I have been able to create branches but than when we create work items , we are not able to search work items for a particular branch . Work items are coming in root project only. Here is my structure
Root Project
- Main Branch
- New Branch
Am i doing it right way? Do i need to create a new project and branch there right under root level ? Like below
Root Project
- Main Branch
New Project
- New Branch
I hope i am able to clear what i want to achieve . Any TFS expert there?
TFS has work item tracking features designed to assist enterprise software development teams to manage their work and software defect tracking. Work Item is for a team project's team, not for a single project/branch (team project and project are not same thing). You can specify Area and Iteration for a work item.
Regarding TFS branch, you would never branch a team project, but branch a project. Check: Branch strategically. You can use branches to accomplish the following goals:
Manage concurrent work by multiple teams on the same codebase
Isolate risks that are introduced by different sets of changes to the
codebase
Take snapshots and then support subsequent isolated changes (for
example, to create a release branch)
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.
I suspect we have a common hierarchy with many other business in that we have software products and we enhance each product through a series of projects.
We have TFS2015 which we host ourselves.
Given TFS does not seem to support the idea of Product I created a TFS project called MyProduct. This 'product' exists in both ALM and SCM.
Next I created my first real TFS Project, i.e. I created a TFS project with the same name as the actual project I have to run for my job. I now have two TFS projects,
MyProduct - this is my master TFS project which I treat as my Product
MyFirstProject - this is my first actual project which I'm executing to enhance my existing product
The source code for MyFirstProject is a copy of the source code in MyProduct and should be merged back to MyProduct at some point or points.
When I am at the end of MyFirstProject I want to move the open work items into my Product TFS Project, i.e. MyProduct, including,
Descoped MyFirstProject stories which I want to keep in my product backlog
Bugs which are detected but not fixed in MyFirstProject
Epics/features which are added during MyFirstProject
Next I want to start MySecondProject, etc etc.
Hopefully this is enough detail around how I believe regular products/projects work and my question is, am I using TFS correctly with this approach? It does not seem natural in that my new TFS projects are not an SCM branch they are a new SCM project and moving work items between projects isn't an obliviously easy thing to do.
It feels like I'm missing the point of the TFS project structure.
I'd like to introduce Team Project Collection and Team Projects.
A Team Project Collection is a group of team projects. When you install TFS, a default collection is created to contain all team projects.
A team project is a collection of source code, work items, build
definitions, release definitions, manual tests, etc. You can have
multiple Team Projects per Collection. You create a team project to establish a repository for source code and a place for a group of developers and teams to plan, track progress, and collaborate on building software solutions. Team projects differ from software application projects or solutions. (Please clarify the TFS project you mentioned in post is a team project or oftware application projects.)
According to your description, MyProduct and MyFirstProject should have branch relationship. So you can create a project A under a team project X, then branch project A to meet your requirement.
Work items is under a team project, not a single software application project. In order to achieve what you want, you can create Teams and Areas and assign work items to different Area.
I have a project folder called as "APP1" . We are currently deploying code from this folder . we would like to create one more folder or branch so that Dev can easily checkin all their new changes without directly affecting the main folder .
Should we have one more branch of folder "APP1" so that Dev can checkin all their changes in the newly created branch and eventually we can merge all the new changes to the main folder "APP1"?
Is this a correct approach and how easy it will be for us to merge all the new changes to the main folder ?
We have team of about 4 developers working on the same project .
You can consider using Basic Branch Plan. The structure like this Development <-- Main --> Release. You can branch your project "Main" into two, one named "Development", the other one named "Release". All users can work in Development branch, after they test their code, then merge to Main branch. When you want to release your project, you can merge your code from Main branch to Release branch.
That would be one way to do it. You'll likely need to play around with differing branching and merging strategies until you figure out what works for you and your team.
There's a large guide put together by the ALM rangers for TFS branching and merging strategies. See https://vsarbranchingguide.codeplex.com/
Here's a picture from one of their guides describing the potential branching/merging strategies that may work for your team, depending on team size and release cadence:
I have the following structure:
$/ProjectA [Uses MS Agile Template]
--Branch1
$/ProjectB [Uses Custom Agile Template]
--[To Be Created Branch]
How can I create this new branch in ProjectB that has a parent relation with $/ProjectA/Branch1?
Our requirement says that we cannot be under the same Project because we must use different templates, but we still want to merge the code from new project back to the ProjectA. I checked the option in TFS when you create a new Project that lets you use an existing source control, but problem with that is:
1.There is NO option to bring in specific branches in a Project [Its all or none]
2.I cannot rename that new branch in the new project for some reason
I understand this can be achieved by using a Baseless merge between these 2 projects but I would like to know if there is still a way to have a smooth merge between these 2 branches in different projects.
P.S: we are using VS 2010 with TFS 2010
There's shouldn't be any problems in just branching from one team project into another. You should be able to do this just like you would any branch: just select $/ProjectA/Branch1, select Branch, and enter a branch target path of $/ProjectB/ToBeCreatedBranch.
This is because realistically, Team Projects are of fairly limited scope in TFS version control - it primarily treats the source control tree as a big hierarchy beginning at $/, and team projects are not particularly special, except for some very specialized operations. (Check-in policies are queried for by Team Project, as are settings for locklevels and labels are scoped to Team Projects.)
I'm a little unclear what version control options you specified when you created the new Team Project - you should have just created a new source tree node for it and then you can create your project branches beneath $/ProjectB.
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