Jeff Lynch [MVP]

Jeff,

We have the same type of setup as you do here at work.  The problem we run into is we sometimes have to make 'changes' to 3 different branches because of changes that have to go out.

We will make changes to the 'production' branch, the 'pilot' branch and the dev branch.  This really sucks and is very error prone.

Derik

Jeff: Just to see if I'm understanding right... Are you saying you usually don't branch and do everything in the main branch (trunk) until a fix is needed for an older release and then branch from a past tag/label to do the maintanance? Or the other way around?

/product/trunk

/product/tags/release.1

/product/tags/release.n

/product/branches/project20000

/product/branches/project20001

/product/branches/project20002

Not the most standard subversion layout.  But given how easy TortoiseSVN merge is, I find it's the best way to deal with a management that change release priorities often.  I'd like to try out TFS some time.

Tomas,

The only time we've branched in the past is when we had to temporarily maintain our R1 production code while developing our R2 code. In our data warehouse project for example, this occurs when we implement a major release of our ERP system which requires us to completely revise our data warehouse tables, views, sprocs and SSIS packages. We need to keep our existing data warehouse & reports up and running while we develop our "new" data warehouse bits. As soon as our ERP system's upgrade has been rolled out, we deploy the new data warehouse bits and disable/delete the old bits.

In our normal day-to-day work, we checkout code from TFS, make our fixes or add new scenarios, test locally or on a test server, check the new bits in and deploy as needed. All in our main branch.

This seems to work for us but it also seems less "robust" than having a three branch configuration like DEV/MAIN/PRODUCTION. My concern is the amount of time we would spend merging very small changes from branch to branch.

Derek,

Thanks for your comments. I'm just not sure what the best way to handle this is for small corporate development teams. I've asked a few folks in the Visual Studio team as well and I'll post what I find out.

Jeff

Matt,

Last year Jeffrey Palermo spend a few hours with me going over Subversion and how he uses this tool to branch and merge. We decided to move ahead with TFS for several reasons but Subversion does have it's appeal!

Jeff

Jeff, I don't particularly like setting up source control along the lines of DEV/MAIN/PROD. I'd say that unless you have very explicit needs that justify adding complexity, stick with what you've got if it works for you. That said, one approach I've seen work well for simple scenarios, is branching before a release (not after). It does require more merges, but, TFS has pretty robust merging capabilities. This works better if you find yourself sometimes working on "v.Next stuff" while also trying to coordinate a release of the current version. Basically the idea is that you're always working on the main branch, which always has the most up-to-date code base. As you approach a release date, you branch that out into a release-specific branch. Stuff that has to be part of this release is then committed to the release-specific branch. Other stuff is done in main, as usual. Then, periodically (or selectively), you merge the release specific branch into main, as needed. If later on, it happens you do need to make a fix in whatever's in production, you've already got a branch there you can work on, and then merge, if needed.

Tomas,

I like this idea a lot and this makes great sense for all my projects (data warehouse, BizTalk, e-commerce web apps, etc). This is similar to what a few of the Visual Studio PMs suggested also.

Thanks,

Jeff

Tomas' method is very similar to what we use where I work. We will only make changes to the branched release if there is a major bug, and then duplicate the changes to the development version of the code. This is a bit of a pain to do, but if you're having to go back and fix major bugs on a regular basis I don't think your source control method is the problem!

Garry,

Thanks for the insight! Most of our bugs are very minor but we do deploy new scenarios (features) on a regular basis.

Jeff

Hi Jeff,

Not really related to branching... It would be very interesting to see how you have defined the areas and iterations for your projects involving BizTalk 06 and SQL Server.

Thanks,

              Thiago

Thiago,

I use one TFS "Area" for each major BizTalk application (Sales Order Processing, Invoice Processing, etc.) and one "Iteration" for the current version and another for future development. In our data warehouse application I use one "Area" for each major section such as databases, SSIS stuff and another for Reports.

Jeff

here's the process that I use, and I think it works very well. and FYI - I've used this process with Visual SourceSafe, Subversion, and CVS... although I called the primary areas something different according to each of the standards for that particular source control system. At this point in time, I use subversion and follow the basic standards that most people use in subversion: Tags Branches Trunk Trunk is where all major development is done for the most recent version of the system. The trunk contains one set of code that is configured to operate in our development environment. When we reach a "release" point and we need to move to Test, User Acceptance Testing (UAT), or Production, we create a Tag for the specific version # and environment (Test, UAT, Prod). Once the Tag is created, we change the configuration for the appropriate environment so that the Tag refelects the correct environment and we can deploy directly to that environment. a Tag is the same thing as a Branch, with the understanding that we never modify a tag's code directly... we only update the config to reflect the environment being delivered to. A branch is created for 1 of 3 reasons: an previously released version needs a hotfix, changes that are needed in the trunk will cause major productivity losses until those changes are complete, and when we need to try something new to see if it works but don't want to hose the real project. if a previous version needs a hotfix, we will Branch from that version's Tag, modify the code, then create new Tags for the new version (i.e. we fix v1.0.1 and it's now v1.0.2). the key points are: Tags: never change anything in here. this is the "history" of releases. Branches: used to make breaking changes or create hotfixes for previously released versions. Trunk: the single main line of development where all new features and functioanlity are developed for the current version. ... in the case where a bug fix is found in a previous release and needs to be propogated to other releases and/or the trunk, we would evaluate the merge feasibility to ensure that a merge process won't break anything between the versions. for example, if the changed file(s) is exactly the same in all releases, we will change it in the trunk and then merge into all of the branch versions that need it. if the changed file(s) is diferent in any version, though, we will make the change by hand and verify through the use of diff tools and regression testing.

Derick,

Thanks for the comments and examples.

Jeff

One tip: dump TFS. It is majorly flawed wrt merging. It can not even merge between sibling branches: suppose you want to port a bugfix in v1.0 to v2.0 you can not merge it directly (baseless merging is _evil_). It has many other flaws as well but that would go too far here. Just migrate to subversion, it is way better in many regards and _much_ more mature. in the new version (1.5) they are even adding merge tracking. If you add TortoiseSVN in the mix you have the perfect GUI that integrates brilliantly with Windows Explorer. No more hassles! Read the Subversion book (or at least the first part): it explains perfectly how to handle branching and merging. You can find it at http://svnbook.red-bean.com/