This project has moved. For the latest updates, please go here.

Basic Branch Plan

Nov 19, 2010 at 9:54 PM
Edited Nov 19, 2010 at 9:56 PM

Hello,

I am new to TFS completely so these will be pretty simplistic questions I assume. I have read over (but not completely understood) HOL_Quick_Start_Basic_Branch_Plan_2010_v1.pdf and  TFS_Branching_Guide_Main_2010_v1.pdf. Currently our shop is uses the following branching strategy:

- Main Branch (equivalent to your release in the documentation)
-- Integration Branch (equivalent to Main in the documentation)
--- Private Group (equivalent to your "Development Folder")
----joe_prvt (joe's private branch)
----sally_prvt (sally's private branch)

I am hoping there is someone out there that can possibly confirm my assumptions on the "Basic Branch Plan". I want to stay as close as possible to the guidelines in our first pass at TFS. I can always make it more complicated.

Questions:
1. I assume my current branching strategy is pretty much exactly the same as the Basic Branch Plan. Please advise if I am mistaken.

2. In the Basic branch plan I only see 1 branch called "Development" in the Development folder. I assume this is just for example purposes. Specifically, if I have 10 developers, each developer would have thier own development branch (like my current strategy) under the Development folder. Is that the idea for the Basic plan? or is the recommendation that each individual developer branch would be a child of the Developer branch; therefore, they would need to first RI to Devleopment then RI Main (and then RI release).

Thanks!

Developer
Nov 19, 2010 at 10:08 PM

I am not sure your branch structure is *exactly* the same as the Basic Branch plan. We recommend against having an integration  branch between Main branch and the Feature branches (your private branches).

I am not sure why each developer needs their own private branch. Typically a team will share the same development branch. Workspaces provide the isolation between developers on the same team. It becomes much more difficult to get changes from one developer to another. When they are working in the same branch, they simply need to check-in changes. But if they are in separate branches, you need to check-in,build, test, merge to the integration layer, build, test, and merge to the second developer, etc.

If you move to the basic branch plan, you would only have a single development branch shared by multiple developers.

Regards,
Bill Heys
VS ALM Ranger

Nov 19, 2010 at 11:15 PM

Thanks for the fast reply.

I think I am getting what is meant by the Development branch based on your explanation Also I know my process does not scale to 100 developers or probably much less than that but we only have 10 right now. I think what I am missing is If I follow the basic guidless the way I'm reading it. If I lose the developers computer, I'm out those changes they did not check in right?

Some Background.
I'm using ClearCase right now, the issue is this with private branches (aka Development branches from the basic branch plan). So I'm working at from that viewpoint. Its one repository to rule them all philosiphy right now. We dont create a branch for a feature. For developer to developer changes, one developer can merge thier code with anothers very simply in clearcase by just merging what they want from that developer. They are in charge of thier own branch so they can do as much shenninigans as they want in there. I can always delete it. In my example if Joe needs a file from sally but she has not yet merged to main he can just merge that file from her branch he does not have to wait until it goes to main.

For us each developer needs to be able to do what they need to do, but they cannot leave code on their computer over night or for any lenght of time it will not get backed up. Some are not located on site thus I cannot enforce a backup locally of thier desktop. They check in thier changes to the server on thier private branch and that gets persisted on the server and then backed up. I dont know how TFS handles this. If having one development branch means developers make changes and leave they are only on their computer until they checkin then I guess that is the answer I was looking for, this will not work.  So in that case  I have to create a branch under the development folder for each developer. so they can check in safely without worrying about effecting other peoples work with incomplete classes. Our day to day process is:

1. Developer Joe works on thier own dev branch. When they pass tests they can RI to main
2. After they pass tests on main they can check in changes to main
3. Developer Sally wants joes changes. she does a FI from main to her branch

In this manner no developer can break someone elses code by simply checking in something incomplete to thier private branch but yet it gets saved and backup at the server. I'm not saying this is the great system it just covers our bases in a simple way. If we lose a computer, we jsut get a new one and they have all thier changes in minutes.

My assumption is that as soon as a developer checks in thier changes on the Development branch in TFS then and only then it is persisted on the server. Then of course its available to anyone using the Development branch when the select "Get Lastest Version" on that branch. Is this correct? What I have to avoid is someone not checking in their changes because its incomplete and thus not on the server. Then if someone spills coffe on their box in the morning we don't lose thier changes because of this. That is why I have created a private branch for each person it solved this issue simply. I do see this idea of "Shelving" but I dont know what that means., do shelves get stored on the server? You also mentioned "Workspaces" is this something that gets persisted on the TFS server itself including all thier code changes? 

You noted on having something between main and feature branchs I'm not sure i understand. I dont see where in the Development branch feature branches come in to play from the documentation on Basic Branch Plan. So I'm assuming they are the same thing?

In my example i think I'm confusing terminology. In my example my integration is the exact same thing as Main. There is nothing between Integration (Main in TSF) and private (ie. Development in TFS).  The only difference I thought was how I handle the "Development Branch". For me each developer has a branch for the Basic Branch plan all developers share 1 thus are constantly able to affect eachothers work.

TFS to My branch mapping terminology in format of TFS = My terminology
Release = Main
Main = integration
Development/Feature = private

 

thanks again!

Developer
Nov 19, 2010 at 11:53 PM

I think there are a number of misconceptions here.

First, if devleopers have their own *private* branch, this does not protect you from losing their computer. Any changes that are not checked in (or shelved) are lost. Branches are server-based, and workspaces are client based. For this reason I generally recommend that developers check-in their changes on a daily basis (or perhaps shelve them).

I typically work with more formal team structures, with several developers participating on a team. As such developers all tend to be working on the same feature and check their changes in daily. Of course changes that are checked in should not break the build for other developers. This is often why I recommend gated check-ins for developers (the code is built first, and check-in can only happen if the build succeeds)

We also have (but do not recommend) the ability to do baseless merges. This might be one way to get changes from one developer to another without going through the main branch. There are a lot of potential issues with baseless merges so we don't recommend them as a general process. Suffice it to say that many many organizations are doing team development this way with TFS - quite satisfactorily.

Maybe my terminology for private branch is workspace. When a developer wants to share changes to one or more files with another.. they check them in. Voila - no merging. The second developer can check them out.

Consider using shelvesets as an alternative to private branches.

The biggest problem with private branches is it increases merges and merge conflicts. What if two developers are working on the same file. It sometimes can become a nightmare to resolve conflicting changes.

[more later]

Regards,
Bill Heys
VS ALM Ranger

Nov 21, 2010 at 8:11 PM
Edited Nov 21, 2010 at 8:18 PM

Bill,

I think I'm almost there on the Basic Branch plan. Your explanations are helping alot. For simplicity I think i understand now compeletely where my branchs map to the basic branch plan. Release is indeed same as my main, Main is the same and my integraton, and Development really where I have deviated. Its the same as my private branches except there is only one in the basic plan where I have 1 per developer. Going foward I think its easier if I ask questions then uing only the TFS terminology. Thank you for your detailed guidance on this. I will help me move forward with some confidence.

I totally agree on the merge conflicts that can (and do) occur when getting files between developers, this does happen from time to time with our approach, however perhaps maybe ClearCase is better than TFS at handling this (but I highly doubt it) or projects are very small compared to most. We work on the same file all the time. That is acutally part of the problem. If a developer is working on a large refactoring (2-3days) in the past they would just have no other choice than to leave it checked out on until they were done with the changes and could reintegrate to the development branch.   We have lost days of work in the past only handful of times in the single development branch senario, but to me thats too many. Thus we created a process that everyone could follow simply (no new concepts) and that could be montiored without complex rules or management overhead. That being each develop at the end of each day must check in their changes. Since they all had thier own development branch they never had to worry about effecting eachothers work. This saved us alot of time in terms of productivtiey, no one thinks twice about checking in their changes to thier own branch.

I think part of my problem is that is the our process as worked well for us, so there is a don't change what isn't broke thought. I'm trying to ignore my fears about changing the process and just try something a little different. I think it comes done to one thing. How do I get my developers changes each day on the server without introducing a branch? The process has to be simple and built into TFS (I dont want to introduce a second tool). I think the trouble for me here is we just have not experienced any issues with merging from our individual development branches to Main. In fact in many cases it saves alot of time for us because our Main is always stable. Anyway, I think my choices are:

1. Keep the same process as I have now because I now know TFS can support this. Side effect is that developers have to merge to main (each one) so it woudl not incur any more time then we are already spending.

2. Move to the new model and try once again a single branch (which had not worked in the past due only to lost changes) and use Shelvesets (assuming they are saved on the server)

I guess Given what you have noted thus far, it seems as a worst case senario to make my transition to TFS from ClearCase smooth I could have a development branch for each developer and still stay somewhat pure with respect to thoughts behind the main and release branches as they are identical to my current process but better. I really like the Read-only Release idea. In the past I have only used Labels.

I'm going to do some research on Shelvesets and see if that will work and report back to this discussion. Thanks for the lead. However in the midterm if I could ask one more question? Is TFS bad at deleting branches meaning does it leave the data in source code database that is not visible to the user even though I deleted the branch. For example, can I delete a branch and its entire history permantely from the database?

BTW I'm personally I'm quite impressed and thankful at the work that was done creating the Branch guidance document. Whoever did that work in documenting that I give a huge thanks to, without this I would have been quite lost.

Cheers

Nov 21, 2010 at 8:26 PM
Edited Nov 21, 2010 at 8:32 PM

Hmmm Shelvesets just might work!!! I'm reveiwing the guideance here ->

http://msdn.microsoft.com/en-us/library/ms181403(VS.80).aspx

One more question or assumption I guess. I assume 2 developers can check out the same file off the Development Branch right? In ClearCase there is the idea of resevered or unserved meaning if you reserve it no one else can check it out, but if you check out unreserved, other developers can canout that same file.

Nov 21, 2010 at 8:42 PM

In VS is called locking… I believe.

From: el3max [mailto:notifications@codeplex.com]
Sent: Sunday, November 21, 2010 1:27 PM
To: Ramon Aldana Borjes
Subject: Re: Basic Branch Plan [TFSBranchingGuideIII:235388]

From: el3max

Hmmm Shelvesets just might work!!! I'm reveiwing the guideance here ->

http://msdn.microsoft.com/en-us/library/ms181403(VS.80).aspx

One more question or assumption I guess. I assume 2 developers can check out the same file off the Development Branch right? In ClearCase there is the idea of resevered or unserved meaning if you reserve it now one else can check it out, but if you unserve the checkout, other developers can.

Read the full discussion online.

To add a post to this discussion, reply to this email (TFSBranchingGuideIII@discussions.codeplex.com@discussions.codeplex.com)

To start a new discussion for this project, email TFSBranchingGuideIII@discussions.codeplex.com@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Developer
Nov 22, 2010 at 12:04 AM
el3max wrote:

Hmmm Shelvesets just might work!!! I'm reveiwing the guideance here ->

http://msdn.microsoft.com/en-us/library/ms181403(VS.80).aspx

One more question or assumption I guess. I assume 2 developers can check out the same file off the Development Branch right? In ClearCase there is the idea of resevered or unserved meaning if you reserve it no one else can check it out, but if you check out unreserved, other developers can canout that same file.

 In TFS, you have the choice of allowing two or more devleopers to check out the same file simultaneously from the same branch (this is called multiple checkout). Or you enforce exclusive checkout to prevent a second developer from checking out a file that is currently checked out.

Developer
Nov 22, 2010 at 12:07 AM
el3max wrote:

Bill,

I think I'm almost there on the Basic Branch plan. Your explanations are helping alot. For simplicity I think i understand now compeletely where my branchs map to the basic branch plan. Release is indeed same as my main, Main is the same and my integraton, and Development really where I have deviated. Its the same as my private branches except there is only one in the basic plan where I have 1 per developer. Going foward I think its easier if I ask questions then uing only the TFS terminology. Thank you for your detailed guidance on this. I will help me move forward with some confidence.

I totally agree on the merge conflicts that can (and do) occur when getting files between developers, this does happen from time to time with our approach, however perhaps maybe ClearCase is better than TFS at handling this (but I highly doubt it) or projects are very small compared to most. We work on the same file all the time. That is acutally part of the problem. If a developer is working on a large refactoring (2-3days) in the past they would just have no other choice than to leave it checked out on until they were done with the changes and could reintegrate to the development branch.   We have lost days of work in the past only handful of times in the single development branch senario, but to me thats too many. Thus we created a process that everyone could follow simply (no new concepts) and that could be montiored without complex rules or management overhead. That being each develop at the end of each day must check in their changes. Since they all had thier own development branch they never had to worry about effecting eachothers work. This saved us alot of time in terms of productivtiey, no one thinks twice about checking in their changes to thier own branch.

I think part of my problem is that is the our process as worked well for us, so there is a don't change what isn't broke thought. I'm trying to ignore my fears about changing the process and just try something a little different. I think it comes done to one thing. How do I get my developers changes each day on the server without introducing a branch? The process has to be simple and built into TFS (I dont want to introduce a second tool). I think the trouble for me here is we just have not experienced any issues with merging from our individual development branches to Main. In fact in many cases it saves alot of time for us because our Main is always stable. Anyway, I think my choices are:

1. Keep the same process as I have now because I now know TFS can support this. Side effect is that developers have to merge to main (each one) so it woudl not incur any more time then we are already spending.

2. Move to the new model and try once again a single branch (which had not worked in the past due only to lost changes) and use Shelvesets (assuming they are saved on the server)

I guess Given what you have noted thus far, it seems as a worst case senario to make my transition to TFS from ClearCase smooth I could have a development branch for each developer and still stay somewhat pure with respect to thoughts behind the main and release branches as they are identical to my current process but better. I really like the Read-only Release idea. In the past I hav

e only used Labels.

I'm going to do some research on Shelvesets and see if that will work and report back to this discussion. Thanks for the lead. However in the midterm if I could ask one more question? Is TFS bad at deleting branches meaning does it leave the data in source code database that is not visible to the user even though I deleted the branch. For example, can I delete a branch and its entire history permantely from the database?

BTW I'm personally I'm quite impressed and thankful at the work that was done creating the Branch guidance document. Whoever did that work in documenting that I give a huge thanks to, without this I would have been quite lost.

Cheers

 Thanks for your great feedback. I am glad you find this helpful.

In TFS you can delete a branch and / or destroy the branch (destroy wil remove the history)

Regards,
Bill Heys
VS ALM Ranger

Nov 22, 2010 at 2:37 AM

Bill,

Ok looks like Shelvesets will work thanks again for that. This is almost too perfect...something has to be wrong :)

I'm going to try to give it a go with a single Dev branch and see what happens. Worst case I cab always create more dev branches.

I do have one last question. If I make my release branch read-only after a FI from main. How do I make bug fixes on it? In the basic plan is the idea make the bug fixes in main and then create a new release branch?

Thanks eduardo7095 and Bill for answering the question about locking a checkout exclusive.

Developer
Nov 22, 2010 at 3:17 AM

If you need to make hot fixes, you might want to consider the standard or advanced plan.

When you are ready to release, branch Main to a Servicing (Hot Fix branch) and then branch Servicing to Release and make Release read-only.

Post Release, you can make bug fixes to the Servicing branch and then RI them to Main.

You don't want to make bug fixes in Main, since at some point it will have vNext code (assuming Release is vCurrent)

Bill Heys
VS ALM Ranger

Nov 22, 2010 at 2:55 PM

Thanks!

For now I think I'm set wish me luck. I'm sure I will have 1 or 2 more questions but this is definitely enough to get started.

Thanks again for all your recommendations and guidance, it was greatly appretiated and was a tremedous help. I'm really not sure what I would have done without all this information.

Cheers!

 

Nov 22, 2010 at 6:36 PM
Edited Nov 22, 2010 at 6:38 PM

Ok so It didnt take long until I ran into trouble

I'm following the TFS_Branching_Guide_Main_2010_v1.pdf and I'm trying to create the folder structure as laid out. Here is what I did

1. Added a Team Project called Base

2. When navigated to source control in Team explorer server\collection\base

3. double clicked on source control

4. Added a new folder called "Main" under base

5. Right clicked on Base and selected "Check in Pending Changes..."

6. Right clicked on Main and selected "Convert to Branch"

7. Right click on Main select "Branching and Merging" -> View Heirarchy

8. Right clicked on Main select "Branch"

9,. Added Dev Branch

10. Went back to source control explorer and tried to Create Dev folder. It would not let me add a  "Dev" fodler where I can put Dev branch under like in the guidance because it says Item Name already exists in source control.

What am i doing wrong.

Nov 22, 2010 at 6:41 PM

If you will have a dev folder, you have to create the dev folder first then create (branch) from main into that folder to get a Dev branch.

You’ll end up with a ‘Dev’ branch in a Dev folder

From: el3max [mailto:notifications@codeplex.com]
Sent: Monday, November 22, 2010 11:36 AM
To: Ramon Aldana Borjes
Subject: Re: Basic Branch Plan [TFSBranchingGuideIII:235388]

From: el3max

Ok so It didnt take long until I ran into trouble

I'm following the TFS_Branching_Guide_Main_2010_v1.pdf and I'm trying to create the folder structure as laid out. Here is what I did

1. Added a Team Project called Base

2. When navigated to source control in Team explorer server\collection\base

3. double clicked on source control

4. Added a new folder called "Main" under base

5. Right clicked on Main and selected "Convert to Branch"

6. Right click on Main select "Branching and Merging" -> View Heirarchy

7. Right clicked on Main select "Branch"

8,. Added Dev Branch

9. Went back to source control explorer and tried to Create Dev folder. It woudl not let me as "Dev" already exists as a branch

What am i doing wrong.

Read the full discussion online.

To add a post to this discussion, reply to this email (TFSBranchingGuideIII@discussions.codeplex.com@discussions.codeplex.com)

To start a new discussion for this project, email TFSBranchingGuideIII@discussions.codeplex.com@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Nov 22, 2010 at 6:44 PM

Thanks that did it!!!

 

Developer
Nov 22, 2010 at 6:53 PM

To further explain

If you have a folder named Main under Team Project Test ... it would be $\Test\Main

You can convert the Main folder to a branch.. it would still be $\Test\Main

You can branch Main to Development (without first creating a folder for the Dev branch)... $\Test\Main -> $\Test\DevFolder\DevBranch  .. in this example it would first create the folder DevFolder and then put the branch DevBranch inside this folder.

You could also create the DevFolder in advance of doing the branch (or have multiple branches inside this folder. You could now branch $\Test\Main -> $\Test\DevFolder\DevBranch2

You can have multiple branches inside a folder as long as you do not have a branch nested inside another branch (in TFS2010 when I talk about branch, I am talking about branch objects, not branched folders)

So if you have a branch, DevBranch under a folder Devfolder you cannot convert DevFolder to a branch - it would violate the nested branch restriction.

You also could not branch a new branch under DevBranch (e.g. branch $\Test\DevFolder\DevBranch -> $\Test\DevFolder\DevBranch\DevBranch3

Regards,
Bill Heys
VS ALM Ranger

 

Dec 6, 2010 at 4:01 PM

Hello,

Just wanted to check back in after I got everything up and running. Using the Basic Branch plan as described now for a couple weeks. Went through a merge with and without conflicts. Works Great!!!

Thanks again for all your help. All of your recommendations and guidance were quite a tremendous help in getting started with TFS branching. I could not have moved so quickly from ClearCase without it. I cannot thank all people that helped me here enough.

Cheers!

Developer
Dec 6, 2010 at 4:17 PM

Thanks for you feedback. I am glad you found the guidance (and discussion list) helpful.

Feel free to ask questions in the future.

Regards,
Bill Heys
VS ALM Ranger

Dec 7, 2010 at 11:46 AM

Bill,

I have on the followingexcerpt from an above response.....

You can branch Main to Development (without first creating a folder for the Dev branch)... $\Test\Main -> $\Test\DevFolder\DevBranch  .. in this example it would first create the folder DevFolder and then put the branch DevBranch inside this folder.

How do you recomend dealing with reference paths to say common shared files that exist in another TFS project. Lets say I had a '$\Common\Binaries' with assemblies that are relatively referenced by code in the $\Test\Main\ folder, now when I branch to $\Test\DevFolder\DevBranch, my relative references back to 'Binaries' is now incorrect.

Would you use an extra dummy placeholder folder on main something like this $\Test\Placeholder\Main. I don't like branching to $\Test\DevBranch1 and $\Test\DevBranch2 to make relative paths work. Am I going about this totally wrong?

Manys thanks for your great support and help here.

 

Dec 7, 2010 at 12:16 PM
wheys wrote:
 In TFS, you have the choice of allowing two or more devleopers to check out the same file simultaneously from the same branch (this is called multiple checkout). Or you enforce exclusive checkout to prevent a second developer from checking out a file that is currently checked out.

Does this apply to a single branch or does it extend to enforce single check-out across all branches for a file?

- Antoni

Dec 7, 2010 at 1:24 PM
Edited Dec 7, 2010 at 1:34 PM

The option Bill is talking about is multiple checkout and when enabled it is enabled across the entire team project source control. See this screen shot for how to enable it:

Developer
Dec 7, 2010 at 9:00 PM

Thanks Allen,

Nicely illustrated!

Regards,
Bill Heys
VS ALM Ranger

Dec 8, 2010 at 8:40 AM

@Allen

If I understand you correctly TFS makes no distinction between a single branch and the whole 'depot' when it comes to parallel check-out, its an all or nothing option.

Which is a serious flaw if that is the case because there are files that should never be checked-out in parallel and there are files that never should be checked-out in parallel on a single branch.

Dec 8, 2010 at 2:25 PM

Tekkie. I agree that it would be nice if there was a distinction between multiple checkout on a single branch or the whole respository. However there is an easy solution use your locking properly.

Dec 8, 2010 at 2:55 PM

I'd call it a workaround, because it relies on the person doing the checkout to do the right thing and as we all know people make mistakes, which in the case of files that should not be modified in parallel can be very costly. ;)

This is one of those things that a tool has to enforce on users as its something that people tend to forget. :(