We're sitting down with CM experts to discuss not just their backgrounds in the field, but what their favorite tools are and why. This week, Steve Berczuk provides a great deal of information on what tools he prefers to use today, and what he would love to see from them in the future.
Noel: What's the primary tool you're working with, and how long have you been working with it?
Steve: I'm currently using Git in my day-to-day project work. Until recently Subversion was the tool that I used most frequently, since about 2002.
Noel: What tools do you have past experience with, and what made you switch to your current favorite?
Steve: I've used the tools that whatever organization I was working at had in place. In most cases this was Subversion. I've also used Perforce, MKS, Star Team, CVS, SCCS, and even Visual Source Safe.
To say that I have a "favorite" would not be totally accurate. When things got challenging with a given tool, I tried to figure out how best to use the tool in our context. In most cases it was possible to make small changes in how we worked to get around problems. Though some were easier to use than others. I've been happy with Subversion, though Git makes some things easier.
The most important this for me that that the VCS supports the work flow that the team uses and that it integrates well with the other tools in the development eco system, like IDEs, issue tracking, and continuous integration systems. A version control system should, in many ways, be almost invisible most of the time. Most modern tools integrate well enough for that not to be a big issue.
The bigger challenge is that the tool enables a work style that works well for the team. In some cases "works well for the team" means that the tool supports the workflow the team already has. In others, it can mean that the tool prefers a workflow that the team can adopt.
Most problems that people have with source code management systems stem from a mismatch between the model the tool has and the model the team wants to use. In some cases, the team's model is the right one for the project, and they really should be using a different tool. In others, the team's vision of how they want to work isn't optimal or hasn't really been thought out. Rather than leveraging the framework the tool uses, they force a workflow onto the tool.
Since version control tools are something everyone one on the team interacts with many times a day, any overhead the tool adds has a high cost.
Noel: What allows a tool to be scalable or adaptable to other organizations or companies?
Steve: Almost any tool can be adapted to the needs of an organization with enough thought and effort. The question is how much thought or effort you want to apply.
For example, when I first started working, I was part of a distributed engineering team, and one roadblock to collaboration was network latency when accessing the code repository. Having the repository local to us meant that the other team would face slow response times. Having it locally to them meant our team would be slowed down.
What we wanted was the ability for each team to be able to "own" their part of the repository while having fast read only access to the other team's code. We ended up developing our own infrastructure for a distributed versioning system using SCCS and unix tools. It wasn't perfect, but solved the problem.
Now between better infrastructure (so having a remote centralized repository is not really a bottleneck) and tools like DVCS, there is less of a need to build your own supporting tools. You still need to think about what the best way for a team to work is, and what could get in the way of efficient development.
So, if we were working on the same project today, we could consider a DVCS, but a Centralized VCS with a reliable fast network connection could also work just as well.