Is it a newbie mistake to avoid branching?

Question

My team is new to versioning and we're trying to keep things simple, as to not overwhelm ourselves with tools-headaches. Also, our product can't be compiled and run locally, so our work is actually more like the whole team modifying a single test server.

So we're thinking that we don't want to make too many branches while we work -- branching means merging, and merging requires practice to do right consistently. (We have to use use TortoiseSVN "because reasons" so better alternatives are not relevant now.)

Is it a "newbie mistake" to think that having many branches is a bad thing because it makes the landscape complicated; of fear that having many branches could more easily confuse us when we need to merge things back together again?

Answer 1

The policy of deliberately refusing to branch is usually a mistake, but I don't think branching is feasible in your case. Not because you are using SVN - which is the usual reason for not using branches, since SVN's handle on branches is especially crappy, even compared to SVN's general crappiness - but because of this:

our product can't be compiled and run locally, so our work is actually more like the whole team modifying a single test server.

This, IMO, is your main problem, and as long as you don't fix this - I don't think you can use branching even if you wanted to. Different developers can't work on separate branches since they are forced to share a working copy. If one developer checks out a branch, that branch will be checked out for the the developers, which means that you miss the main advantage of branching - allowing multiple developers to work on different features of the same project without getting between each other's legs.

So, you can't use branches to coordinate the collaborations, but solo developers(that use SCMs that are not total garbage - which is not your case here, but let's ignore it for the point of the debate) also use branching - e.g. to test new features that may or may not be merged or to explore the system in a scrapable branch.

Can you use branches in such a way? Well, even if you are OK with moving the whole team to a feature branch or to a scrapable branch - how do you plan to coordinate it? Will you use email, or install a PA system where you can announce WE ARE NOW MOVING TO FEATURE X'S BRANCH? And what will you do when some dev is in the middle of something in the current branch? Will you make them roll it back, or make the entire team wait for that developer to finish?

Do you really want that headache?

Another point to consider - branching usually needs some level of cleanness in the build process and project tree structure, so artifacts of one branch won't leak to other branches when you switch branches. SCMed projects usually have that - or else they wouldn't be able to build on all the machines of all the developers - but seeing that your project can only build on the test server I doubt you have that minimal level of cleanness. Oh, your branches will probably work - at least in the beginning, until a leaky artifact will surprise you with some weird, hard-to-detect bugs.

Answer 2

It is certainly a mistake, but not necessarily only a newbie mistake.

At my last job (a highly competitive motorsports job) my boss was adamant about avoiding branching. He had about 20 years experience and still thought it was a bad idea.

I completely disagreed with him and challenged his misconceptions. There are times where branching isn't worth the potential hassle it brings. Yet, there are other times where it is clearly the only sane solution (eg, two teams doing two parallel but separate iterations of work on the same source code). Just like everything else in life, you shouldn't have a blanket rule about it.

So, yes, it's a mistake. No, it's not just a newbie mistake, though it should be.

Answer 3

Keep in mind that the only purpose for branching is isolation. You branch when you want to be able to make changes in location A without impacting location B. Having a branch adds work, so you want to create a branch when the benefit of having the branch outweighs the pain of the overhead involved.

For example, creating a branch to fix a small bug is crazy - the work involved in creating a branch and merging is probably going to be way more than what it takes to fix the bug. On the other hand, you absolutely want a branch for a major release. You need to have a stable code base with controlled fixes.

Anything in between is a judgement call and really depends on the size of the team and how the team works. Here, I work on a team of 3 people and we only have the mainline and release branches. If I was working in a group of 10+ people, I'd expect that we'd have more branches.

Also keep in mind that branch depth is important because it dictates how many merges you need to do. One common setup is to use individual developer branches that hang off of an integration branch, which then hangs off of main. In this scenario, a bug fix from a developer branch going to a release needs to be merged, built, and tested 4 times (dev->integration->main->release). That's a lot of overhead, so there better be tangible benefits from having those branches.