Entries Tagged 'Tech industry' ↓

I’m hoping some of us remember when subversion was first released. Those of us CVS users knew immediately that subversion’s changeset-based tracking was a big improvement.

Some of us held off a little while until the tool support had matured, but after a few months there was no great benefit to sticking with CVS, and subversion spread quickly. In a short time, it became the free source control system of choice.

Switching to subversion fixed a problem that with CVS, but it didn’t fundamentally change how we’d used source control as a team. That’s important.

The rationale for switching a team from subversion to git is less clear-cut and, I’m going to argue, you could end up affecting how your team works together for the worse.

Git is a more complex tool, but that’s not necessarily a bad thing, and I have no doubt it will get simpler tooling with time. Its speed is a huge improvement over svn and for some I’m sure sufficient reason to change. And, of course, it doesn’t drop pesky .svn folders all over the place. All improvements, straightforwardly.

But, if subversion is a team-based tool, git is designed around individual developers, loosely-connected in social groups. This distinction is what makes git an excellent social tool – an excellent choice for software developed by a diverse group of individuals as open-source projects often are. Just for the record, github rocks.

However, git’s group-development virtues are team-development vices.

Branching is an evil for small teams. Single-trunk development with continuous, often, easy integration leads to fewer bugs, better communication between team members, sharper code. I’d go further than most agile proponents here: if your team is small enough to handle it, this is what you should do; if it isn’t, it’s time to split the team.

On the softer side, the commitment that a team-member makes to keeping the trunk clean is important in itself. It’s these norms and commitments, personal promises and bindings that make the difference between a team and a group of individuals. And, our chosen tools are a part of that team structure.

Git is a gift for those people on your team who are not team players, but not necessarily a boon for the team. I’ve seen this play out a couple of times now, surely others have too?

So, what I think most teams would do better with is a subversion that’s faster and doesn’t leave .svn folders around, one that’s easy to set up and doesn’t have 200+ commands to play with. Perhaps if subversion were up on github we could all have a go at making it.