While having a conversation this week with a friend, I made the lofty declaration that implementing good upstream contribution processes is more important than the tools used with those processes. The topic came up after a story about a team using an open source project internally at work were receiving complaints from their upstream community when they contributed their changes back in the form of large, monolithic patches, i.e. code drops. The obvious solution would be to do all your development in the open from the start. That's not always possible for various business and intellectual property reasons and sometimes patches are embargoed until a public disclosure date, which was the case for this team.

While contributing changes back to the community certainly earns you some open source kudos, speaking as a maintainer, no one likes receiving these huge patches. They don't include the valuable context and engineering insights that went into developing them. Does it fix bugs that might affect me? What was going through the engineer's mind when they wrote this? Who knows.

Patches sent upstream need to relay the development process that occurred when they were written. Which makes it important that your process of pushing patches upstream mirrors you internal development process - so you don't lose that valuable development context. Some version control systems (VCS) make this easier than others and the team were pushing for moving the upstream project from CVS to git.

Then my friend asked:  Which would you suggest the team do first? Switch to git or iron out their upstream patch submission process?

I quickly reeled off a couple of reasons why, generally, procedures were more important than tools and getting the developers to think a certain way was the hardest battle and should be tackled first. Moving to git would simply allow them to optimise their workflow and would be a small incremental change that would be the icing on their cake.

Then I sat down and tried to use CVS and realised I was completely wrong.

The problem is that some VCS make it so difficult to implement a correct upstream process that it actually dissuades you from doing things right. CVS requires a downright herculean effort to mirror upstream the development that happened internally. Your best option is to contribute the changes upstream in a separate branch and have that branch merged into the trunk. But that isn't much better than the monolithic patch option because reviewing the changes is still painful, requires contributors to have access to the upstream CVS repository and introduces new, unwelcome challenges like solving merge conflicts.

git on the other hand not only makes it simpler to mirror your development openly, it actively encourages it. Patch history can be "replayed" onto any repository, so even if contributors don't have access to the upstream repository they can submit patches to the project mailing list which will give you the same commit history. Granted, the commit hashes will be different but git is smart enough to deal with that as long as the patch content is the same.

I still think that processes are more important than tools, most of the time. But the scenario in the above story demonstrates that you can't implement good processes with crappy tools.