Applying source code changes directly to Root

Question

Ok I am not sure if this has ever been asked since it seems like a complicated/contextual type question.

If a development team works with several source branches from one main branch (root/trunk etc), would you always just want to make changes on your particular branch and then merge to (root/trunk etc) when the change has passed QA?

I am seeing a situation now in my SVN where maaaany people are getting lazy and applying changes directly to trunk. Supposedly to save time merging and QA'ing the new trunk build. Isn't that contradictive to the whole idea of separate branches?

Hopefully this post is somewhat clear.

Answer 1

It depends on your organization.

If you have an organization where one person or team is responsible for reintegrating everything in the main trunk, and all the other teams are working on clearly separated parts, branches probably work fine.

On the other hand, we have an organization where code changes regularly overlap and working with branches would introduce a nightmare. In our company, everyone commits in the main trunk. This also means that everyone is responsible for keeping the trunk alive.

In the latter case, take the necessary steps to make everyone aware that they are responsible for keeping the trunk alive, e.g.:

• Use something like CruiseControl to compile the trunk and run unit tests in a continuous way. If it fails, mail it to the offenders.
• Put a big traffic light in the office and light up the red light if the trunk does not compile anymore or any of the unit test fails. Normally the light should always be green.
• Put a jar in the centre of the office. If someone breaks the trunk, he must donate some money (1 dollar, 1 euro, ...) in the jar. At the end of the year, take the whole department to a nice restaurant with the money.

Answer 2

We use trunk for most of our commits. We consider it the "current version" branch. When we send a version to the testing group, we peel off a separate branch for it, and then any fixes coming out of testing are made to that branch and eventually merged back to trunk.

We used to use a strategy where every project got a separate branch, and when we were ready to deploy we merged them all together. This proved to be a nightmare. We got conflicts all the time, and then the person doing the merge would sit there and try to guess his way through resolving the conflicts, and once he got something to successfully compile, it would be turned over to user acceptance testing. Worse still, we had a number of occassions where SVN thought it had successfully merged two branches so it did not generate any conflict warnings, but in fact the merge did not work.

While SVN is very smart about merging, it's far from infallible, and the more merges you do, the more often there will be problems. Our new strategy is to minimize the number of merges.