Do you feel comfortable merging code?

Question

This morning, I read two opinions on refactoring.

• Opinion 1 (Page not present)
• Opinion 2 (Page not present)

They recommend branching (and s

Answer 1

Working in a code base of millions of lines of code with hundreds of developers branching is an everyday occurrence. The life of the branch varies depending on the amount of work being done.

For a small fix:

• designer makes a sidebranch off the main stream
• makes changes
• tests
• reviews
• merges accumulated changes from main stream to sidebranch
• iterates through one or more of the previous steps
• merges back to main stream

For a multi-person team feature:

• team makes a feature sidebranch off the main stream
• individual team member operates on feature sidebranch as in "small fix" approach and merges to feature sidebranch.
• sidebranch prime periodically merges accumulated changes from main stream to feature sidebranch. Small incremental merges from the mainstream to feature sidebranch are much easier to deal with.
• when feature works, do final merge from main stream to feature sidebranch
• merge feature sidebranch to main stream

For a customer software release:

• make a release branch
• deliver fixes as needed to release branch
• fixes are propogated to/from the main stream as needed

Customer release streams can be very expensive to support. Requires testing resources - people and equipment. After a year or two, developer knowledge on specific streams starts to get stale as the main stream moves forward.

Can you imagine how much it must cost for Microsoft to support XP, Vista and Windows 7 concurrently? Think about the test beds, the administration, documentation, customer service, and finally the developer teams.

Golden rule: Never break the main stream since you can stall a large number of developers. $$$

Answer 2

The branching problem is why I use a Distributed Version Control system (Git in my case, but there are also Mercurial and Bazaar) where creating a branch is trivial.

I use short lived branches all the time for development. This lets me mess around in my own repository, make mistakes and bad choices, and then rebase the changes to the main branch so only clean changes are kept in history.

I use tags to mark frozen code, and it is easy in these systems to go back and branch off these for bug fixes without having a load of long lived branches in the code base.

Answer 3

If merging is too much of a pain, consider migrating to a better VCS. That will be a bigger pain, but only once.

Answer 4

Branching might be painful but it shouldn't be.

That's what git-like projects (mercurial, bazar) tells us about CVS and SVN. On git and mercurial, branching is easy. On SVN it's easy but with big projects it can be a bit hardcore to manage (because of time spent on the branching/merging process that can be very long -- compared to some others like git and mercurial -- and difficult if there are non-obvious conflicts). That don't help users that are not used to branch often to have confidence in branching. Lot of users unaware of the powerful uses of branching just keep it away to not add new problems to their projects, letting the fear of the unknown make them far from efficiency.

Branching should be an easy and powerful tool we'd have to use for any reason good enough to branch.

Some good reasons to branchs:

• working on a specific feature in parallel with other people (or while working on other features alternatively if you're alone on the project);
• having several brand versions of the application;
• having parallel versions of the same application -- like concurrent techniques developped in the same time by to part of the team to see what works the better;
• having resources of the application being changed on a artist/designers (for example in games) specific branch where the application is "stable" while other branches and trunk are used for features addition and debugging;
• [add here useful usages]

Answer 5

We use svn. It only takes us about 5 minutes to branch code. It's trivial compared to the amount of pain it saves us from messing up trunk.

Answer 6

Branching and merging should be fairly straightforward.

• I feel very comfortable branching/merging.
• Branching is done for different reasons, depending on your development process model/

There's a few different branch models:

Here's a one

  Trunk          
  .      
  .      
  .      
  ..         
  . ....     
  .   ...
  .      ..Release1
  .      
  .      
  ...        
  .  .... 
  .    ...Release2
  .      
  .      
  ..         
  . ...  
  .  .. 
  .    ...Release3
  .      
  .      

Now here's a curious thing. Suppose Release1 needed some bugfixing. Now you need to branch Release1 to develop 1.1. That is OK, because now you can branch R1, do your work, and then merge back to R1 to form R1.1. Notice how this keeps the diffs clear between releases?

Another branching model is to have all development done on the Trunk, and each release gets tagged, but no further development gets done on that particular release. Branches happen for development.

  Trunk                                           
  .                                                         
  .                                                         
  .                                                         
  .Release1           
  .                       
  .                       
  .                   
  .                   
  .Release2           
  .                   
  .......                 
  .      ......       
  .           ...DevVer1
  .          .    
  .          .            
  .        ...DevVer2
  .      ....         
  .  ....             
  ...                     
  .Release3           
      .

There may be one or two other major branch models, I can't recall them off the top of my head.

The bottom line is, your VCS needs to support flexible branching and merging. Per-file VCS systems present a major pain IMO(RCS, Clearcase, CVS). SVN is said to be a hassle here as well, not sure why.

Mercurial does a great job here, as does(I think)git.