A Branching and Merging Primer

re: A Branching and Merging Primer

Stephan — Sun, 13 Nov 2005 19:27:03 GMT

Wow really helpfull :)

Thanks for explaining!

re: A Branching and Merging Primer

Tomas Restrepo — Sun, 13 Nov 2005 22:09:54 GMT

Excellent couple of post Brian, this is not only very informative, but also gives us some nice ideas as to how to use the product. Thanks!

re: A Branching and Merging Primer

Vineeth Raja — Sun, 13 Nov 2005 22:17:10 GMT

Thanks for the great post. Very useful and clearly explains the concept.

re: A Branching and Merging Primer

Keith Hill — Tue, 15 Nov 2005 02:56:07 GMT

Great stuff! Can you elaborate a bit more on how each developer is able to just build from any dir? The thing I struggle with when thinking about building using path space branching is how to get a single nightly build script to work for multiple developers when they are likely to be building off of different branches. In SCM products like TFS these different branches manifest themselves as different directories. With our current SCM system which uses version space branching this isn't a problem because everybody's directory structure is the same even if they are using different branches.

re: A Branching and Merging Primer

bharry — Tue, 15 Nov 2005 16:21:21 GMT

I'm not sure I thoroughly understand your scenario - but a few comments and you can re-ask the question if I missed it.

I don't know the details of what we put into the project files to enable the tree to be built at any level. The TFS build guys did it and I'm sure they'd be happy to blog about it. I'll send them mail and ask them to post something.

We don't have a "single nightly build". We have one nightly build for each VBL. Individual developer branches don't get built by the build lab but rather are built as needed by the developers who use them. Some set up rolling build machines (continuous integration), others just do it manually when they need a build.

Code only makes it into an "official" build when the code has been RI'd into one of the build lab supported VBLs.

re: A Branching and Merging Primer

Keith Hill — Tue, 15 Nov 2005 19:27:39 GMT

Our development teams are small enough usually where we have a single KornShell script checked into $/ProjectName/Build/Scripts called DevNightlyBuild.ksh that rebuilds on a developer's PC every night. Each dev sets it up in the task scheduler passing in their email address as the one and only parameter (to mail failure messages). This works great when everyone's directory structure (relative to the project root) is identical. I'm just trying to wrap my mind around how to make this work when folks start using private branches in a path spaced branching SCM tool. All of a sudden each developer may not want to build $/proj/Trunk/Src/Foo but instead build $/proj/Branches/Dev/Joe/Foo. I don't think this is insurmountable or anything. I just need to ponder on this some more. :-)

re: A Branching and Merging Primer

bharry — Wed, 16 Nov 2005 06:13:25 GMT

Ahh, I think I understand the heart of your question. Our build environment is a command shell that is initialized by running a script called razzle.cmd that sits in:

<vbl root>\tools

It knows where it is relative to the root of the VBL (it's always in the tools subdirectory) and sets an environment variable to the root of the workspace on the user's local machine. Then all of our build scripts are parameterized by that environment variable.

So, using an example. I may want to enlist in $/VisualStudio/lab23. It contains all of the tools, publics, source, etc. I map the directories I need into my workspace:

$/VisualStudio/lab23/tools -> d:\dd\tools
$/VisualStudio/lab23/vset -> d:\dd\vset
and so forth for all of the folders I need.

I then open a command prompt and run d:\dd\tools\razzle (optionally passing a parameter indicating whether I want debug or retail). It sets up environment variables, including one calls NTROOT (Don't ask why it's called this. It's legacy because this system started in Windows). It will set

NTROOT = d:\dd

Because it knows it's always right below the root. Now I can cd to any folder in the tree and build it and it knows where the root is (and can therefore find tools, public, etc) because of the environment variable.

As a side note, I'll mention that not every private branch includes a whole VBL. It's too much stuff to branch for small projects - something like 500,000 files. It's not uncommon to branch $/VisualStudio/private/FeatureX from $/VisualStudio/lab23dev (or one of the other full VBLs) by only branching the subset of subfolders that you need and then have clients create a workspace that maps from both branches. For example:

$/VisualStudio/lab23dev/tools -> d:\dd\tools
$/VisualStudio/private/FeatureX/vset -> d:\dd\vset

I hope this helps.

Brian

re: A Branching and Merging Primer

Graham Allwood — Thu, 17 Nov 2005 15:27:25 GMT

Hey, this is cool, learning from people with such experience has to be a winner; thanks.

A question though. You say the Public folder contains all libs and assemblies the projects reference, including Framework and SDKs. I'm sure the answer is yes, but does this mean that say one of your projects needs the mobile 2005 SDK, rather then referencing something from the GAC (which is why the SDK installs its assemblies), you would copy that assembly from the default installed folder to the Public folder (or a subfolder in here) and reference that instead.

I can see that advantage for doing this with most SDK's, but the Framework? Surely this is required on the build machine anyway?

Wait, hang on, you also copy the compilers to the tools folder don't you, then I bet you reference these from the build script.

re: A Branching and Merging Primer

bharry — Fri, 18 Nov 2005 00:19:47 GMT

Right, we copy everything. The .NET Framework, all SDKs, compilers and everything to the version controlled tree. This way the tree is pretty much entirely stand alone and makes almost no assumptions about the machine's environment. You pretty much just need a properly installed copy of Windows and the version control tools (so you get get all the rest) and you are good to go.

It makes the tree kind of big but gives us a lot of flexibility to be building things against different versions of the Framework, update the tools and distribute them to the team in a controlled fashion, etc.

Brian

re: A Branching and Merging Primer

Graham Allwood — Fri, 18 Nov 2005 11:24:31 GMT

Another question for you Brian...

Do you think that would could ever use Team Build to run your nightly builds are is the Razzle script a little too complicated? Sorry, this is a little off topic (i.e. not branching or merging).

re: A Branching and Merging Primer

bharry — Fri, 18 Nov 2005 17:17:51 GMT

We've actually already integrated some of TFS Build into our nightly build process. We don't use the TFS build launching capability (we really don't want random people around the division starting builds anyway).

Over the next 6 months or so we will be integrating more of it. Our build is big enough and complicated enough that I don't forsee us using any TFS Build "out of the box" configuration in the near term.

We designed TFS Build to be more of a set of building blocks than a turn key solution. We recognize that build processes can be very complex and customized to the needs of each organization. As a result we tried to deliver discrete components for things like labeling the source, generating a build number, running tests, updating work items, etc. This way people can integrate these tasks into what ever custom build process they have.

The "out of the box" TFS build configuration will work for smaller projects and will save a lot of time putting together a build process. In future versions, we will continue to expand the scope of what the out of the box solution can handle (for example adding support for parallelization of the build process, tasks for code signing, etc).

Quickie: bharry on VBLs and branching

Stuart Celarier — Sat, 22 Apr 2006 16:36:20 GMT

A couple of posts by Brian Harry (bharry) from November 2005 about virtual build labs and branching on the TFS project...

Pozo T??cnico » Blog Archive » Branching en VSS

Pozo T??cnico » Blog Archive » Branching en VSS — Thu, 24 Aug 2006 17:54:10 GMT

PingBack from http://www.pozotecnico.com/?p=143

Branching strategies for TFS

My VSTS Blog — Wed, 13 Sep 2006 00:52:38 GMT

There has been a few discussions (Eg. Brian Harry , Martin Woodward , MSDN Forums ) and even a session

re: A Branching and Merging Primer

Johan Bergens — Fri, 29 Sep 2006 00:44:58 GMT

Hi!

A bit late, but...
I would like to see a clarification of how you handle the potentially large number of branch folders below "branches" (or the root). Do you create a nested structure from the beginning and use the leaf nodes or do you keep all branch folder below a common parent (the root or "branches")?

I tried to ask the same question in another forum but tries to rephrase it here to make it easier to understand and to connect to your example.

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=773007&SiteID=1

re: A Branching and Merging Primer

bharry — Fri, 29 Sep 2006 16:59:16 GMT

This has been evolving some as our number of branches grows. The current organization of branches for Orcas (our next version) looks something like this:

$/Orcas - The Team Project

$/Orcas/Main - The main branch from which the final product is built.

$/Orcas/PU - Contains a flat list of branches - one for each product unit. Under here each product unit has a branch (e.g. $/Orcas/PU//VB and $/Orcas/PU/VSTS, etc) where work from each of their feature teams is merged and tested before being merged into $/Orcas/Main.

$/Orcas/Feature - For Orcas, each "feature" is being developed in its own branch for isolation from the churn induced by other feature teams. This folder contains a branch for each feature team to work in (e.g. $/Orcas/Feature/LoadTest or $/Orcas/Feature/VCClient01, etc) before merging their changes into their PU branch. Today this is a flat list under $/Orcas/Feature but you could imagine creating some hierarchy to manage it.

$/Orcas/private - This is a container for random "personal" branches that anyone wants to create and use for a period of time.

Hope this helps,

Brian

Microsoft SCM 的策略 -- from BHarry

Refines.Info["Polo Lee"] — Sat, 20 Jan 2007 18:52:34 GMT

bharry's WebLog : A Branching and Merging Primer Branch structure in Developer Division at Microsoft

Please help: Merge options are disabled

guyRonen — Thu, 08 Feb 2007 16:01:32 GMT

I am using TFS.

I have created a brunch for project proj1 which is called proj1B.

After modifing one of the files in proj1B, chek-in and merge to proj1, the modification was automatically merged into proj1.

If I modify (adding a method) on of the files in proj1, then modifying it also in proj1B (also adding a method), both check-in ---> When I come to merge proj1B to proj1 i get the conflicts dialog (which is fine) with the "Auto Merge All" button DISABLED. When I click on the "Resolve" button, I get the resolve options dialog with the first two merge options also DISABLED ("Merge changes for me" and "Merge changes in merge tool").

I have full permissions.

Resources for Today's TFS Live Meeting

Microsoft UK Developer Tools Team — Wed, 28 Feb 2007 11:39:33 GMT

TEAM FOUNDATION SERVER Team System Overview http://msdn2.microsoft.com/en-gb/teamsystem/aa718836.aspx

re: A Branching and Merging Primer

Neha — Mon, 14 Apr 2008 21:33:17 GMT

Hi,

What if I want to branch only a few items from Parent into the Child and not everything that's there under Parent. How to accomplish that?

I tried two ways of branching:-

1. Create a New Team Project and folow the wizard. It will prompt you to branch from an existing TeamProject. You may choose that or skip. If you choose it, it will branch everything from Parent to Child.

2. Just create an empty TeamProject. Right click the Parent and select Branch. Enter the appropriate paths.

Option 1 maintains the links b/w the Parent and Branch but Option 2 doesn't. Do you know a way to branch just a few files from Parent to Child but with ability to keep the links?

thanks!

bharry's WebLog : A Branching and Merging Primer

Dating — Sat, 31 May 2008 17:57:53 GMT

Hmm, OK I guess I jumped too quickly into using unfamiliar terminology. Let me step back and define some of the concepts/terms a little more and then hopefully that last post will make more sense. The Source Tree Let’s start with what the source tree

bharry's WebLog : A Branching and Merging Primer

Weddings — Fri, 06 Jun 2008 00:37:30 GMT