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

We use StarTeam and we only branch when we have a situation that requires it (i.e. hotfix to production during release cycle or some long reaching project that spans multiple release windows). We use View Labels to identify releases and that makes it a simple matter to create branches later as needed. All builds are based on these view labels and we don't build non-labeled code.

Developers should be following a "code - test - commit" model and if they need a view for some testing purpose or "risky" development they create it and manage it. I manage the repository and create branches only when we need them. Those times are (but not limited to):

• Production hotfix
• Projects with long or overlapping development cycles
• Extensive rewriting or experimental development

The merge tool in StarTeam is not the greatest, but I have yet to run into an issue caused by it. Whoever is doing the merge just needs to be VERY certain they know what they're doing.

Creating a "Read Only Reference" view in Star Team and setting it to a floating configuration will allow changes in the trunk to automatically show in the branch. Set items to branch on change. This is good for concurrent development efforts.

Creating a "Read Only Reference" view with a labeled configuration is what you'd use for hot fixes to existing production releases (assuming you've labeled them).

Answer 2

Branching is trivial, as most have answered, but merging, as you say, is not.

The real keys are decoupling and unit tests. Try to decouple before you branch, and keep an eye on the main to be sure that the decoupling and interface are maintained. That way when it comes time to merge, it's like replacing a lego piece: remove the old piece, and the new piece fits perfectly in its place. The unit tests are there to ensure that nothing got broken.

Answer 3

I use Subversion and consider branching very simple and easy. So to answer question 1.. Yes.

The reason for branching can vary massively. I branch if I feel I should. Quite hard to put rules and reasons down for all possibilities.

However, as far as the "Allow a developer to walk away from risky changes." comment. I totaly agree with that one. I create a branch whenever I want to really play around with the code and wish I was the only developer working on it.. When you branch, you can do that...

Answer 4

We use svn and have adopted a rule to branch breaking changes. Minor changes are done right in the trunk.

We also branch releases.

Branching and merging have worked well for us. Granted there are times we have to sit and think about how things fit together, but typically svn does a great job of merging everything.

Answer 5

Branched have to be managed correctly to make merging painless. In my experience (with Perforce) regular integration to the branch from the main line meant that the integration back into the main line went very smoothly.

There were only rare occasions when the merging failed. The constant integration from the main line to the branch may well have involved merges, but they were only of small edits that the automatic tools could handle without human intervention. This meant that the user didn't "see" these happening.

Thus any merges required in the final integration could often be handled automatically too.

Perforces 3-way merge tools were a great help when they were actually needed.

Answer 6

I've been on a project using svn and TFS and branching by itself is a really simple thing.

We used branching for release candidate as well as for long lasting or experimental features and for isolating from other team's interference.

The only painful moment in branching is merging, because an old or intensely developed branch may differ a lot from trunk and might require significant effort to merge back.

Having said the above, I would say that branching is a powerful and useful practice which should be taken into account while developing.