ADVICE: TFS Branching

redeye_uk

redeye_uk

redeye_uk

Associate
Joined
1 May 2007
Posts
1,901
Location
London
Hi all, need some advice with how best to branch our code.

Currently we have the following setup...

$Project
/MainLine​

coders develop, check-in, merge etc against this one line and we label the code to signify a release. Really bad practice I know, but its been that way since I joined.

Problem with the current setup is we have customers using old versions of the code and when it comes to fixing a bug for them it is a royal pain trying to track down their version of code. Once a fix/patch or whatever has been produced it can be a bit risky checking-in a fix. So naturally branching is the way forward?

I was thinking of the following setup

$Project
/Mainline​
/Releases​
/release1.1​
/release1.2​
/release1.3​
/Customers​
/Customer1​
/Customer2​

so basically all development occurs in the mainline and then say once a month we create a new branch and add it to /Releases. Same applies to /Customers, when we give them a release we make a new folder for said customer.

Am I right in thinking if customer1 then needs a bug fix or some custom functionality outside of the core product I can get latest of /Customer1, code a fix and then check-in against the customer1 branch? (So I dont merge the fix with /Mainline or /Releases).

Really just asking for advice on how to best lay out the branching as I have never done it before and just want to check my thinking is logical and future proof.
 
Google for "repository branching" to read many, many "tutorials" and guides on branching.

In summary though:

/trunk
- This is where the work gets committed.
/builds
- These are builds (snapshots of trunk) proposed for release
/releases
- These are released builds. Read-only. Once a release is made for a version, no more builds for that version can be made.

So an example:

Code: 
/trunk

/builds
  /1
    /1
    /2
  /2
    /1
    /2
    /3

/releases
  /1
  /2
Where the numbers are versions. So the path for build version 1 build 2 would be /builds/1/2, and the path for release version 2 would be /releases/2.
 
Cheers Jestar

In the end I followed this guide and have gone for Scenario 3 – Branch for Maintenance. It seems to be geared towards my exact requirements without being overly complex.
 
I can't view the video, don't have Silverlight installed (and cba to install it) however I would like to point out that branching and merging is quite inefficient. Continuous Integration is where it's at :)
 
Branching/merging on TFS/SVN is inefficient. CI doesn't solve that or really have anything to do with it. Otherwise everyone would just only ever have a main trunk and constantly check-in changes to that. Which isn't maintainable or scalable on projects that have multiple features being developed concurrently or where multiple versions need to be maintained.

Git/Hg make branching/merging far more efficient.
 
NathanE said:
Branching/merging on TFS/SVN is inefficient. CI doesn't solve that or really have anything to do with it. Otherwise everyone would just only ever have a main trunk and constantly check-in changes to that. Which isn't maintainable or scalable on projects that have multiple features being developed concurrently or where multiple versions need to be maintained.
Click to expand...
Disagree. :)

All that branching/merging does is delay/accumulate all commits until you merge in one fat lump. CI eliminates this wasted time. :)

We've got multiple dev-teams, all working with CI on various sized projects. It is far more efficient to be using CI than it is to branch/merge.
 
You must log in or register to reply here.
Back
Top Bottom