Glenn Block began an interesting thread on the public “altnetseattle” email list on Thursday:
I know we just finished a nice thread about GIT, whether it’s hot and why.
We also talked about alternatives like Bazzar, Mercurial, etc…
A different question I have is do these tools (regardless of which one you
use) actually support Agile development? Would you consider them an integral
part of the agile shop of the future, or is it just "the way" to do it
regardless. What I am really asking is are there specific benefits for those
doing agile development?
Glenn” – Glenn Block
Now, Glenn is one of those really smart guys. You can learn more from someone not by listening to what answers he gives; but by what questions he asks.
The thread has some great discussion, but here is my answer that I posted:
“Every VCS supports agile. Agile is the way the team works with the VCS, not the other way around. DVCS systems make branch-per-developer seamless. With Subversion, it is easy to have multiple people working off the trunk, and the merging is great. Tools like JetBrains TeamCity will do auto-patch-upload and run the private build remotely at any time so you have build-per-developer without waiting for the local machine.
TFS and VersionManager need more work in order to have multiple people making changes to the same files simultaneously, but agile teams still use them.
Also, the VCS features have a lot more to do with supporting a team SIZE, not a team PROCESS or PHILOSOPHY. A BDUF team of 2 and an agile team of 2 will probably have similar experiences in wide range of VCS’s. BDUG teams of 10 and agile teams of 10 will have VERY different experiences based on the VCS in place.
I think the essence of the situation is providing the most versioned "levels of undo" possible. In John Maeda’s The Laws of Simplicity book, he talks about how putting "undo" everywhere makes the experience of using a product seem simpler. It may not be simpler, but the impression is that it IS simpler. With Git (the only DVCS I have experience with),:
- I can revert a local commit
- I can revert a push to my fork
- I can revert a pull to the master
- I can revert a commit on the master
- I can revert a push to the master
With a centralized system, I can only revert a commit to the centralized branch (along with roll-your-own branch commits and merges).
We need only look at some of the large, fast-moving projects hosted with Git to see that is "supports" whatever it is that we are labeling "agile" these days. http://git-scm.com/
Charlie Poole, a lead committer on the NUnit open source project, weighed in early and posted something so profound, I just have to share it.
Charlie has so much experience in software that when he speaks, I listen intently. I have had the please of meeting him at several Alt.Net conferences. Here is his first post on the thread:
I consider DVCS to be agile on a philosophical and practical level.
Philosophically, agile is supposed to be *not* so much about tools. DVCSs
remove many of
the restrictions imposed by centralized tools. Most of them work well in
either mode, so a team
can set up it’s own practices and not be limited by what the tool can do.
One proof of this is that some shops forbid DVCSs because they don’t give
control over developers – a very non-agile viewpoint.
In practical terms, a DVCS allows me to work how and where I want, creating
branch if I need to, or keeping a common personal branch for small changes.
I can work
quickly on a spike, throwing it all away or merging it in as I like. This is
something I used
to do with multiple workspaces under SVN or CVS, but when I wanted to merge
different workspaces without touching the repository, I had to do it
So I’d say that DVCSs are a win no matter how you develop, but are a
good fit for agile development.
Charlie has undoubtedly used twice as many Version Control Systems than I have, so when he compares a DVCS to all the others in his past and calls it a “win”, that’s a pretty strong endorsement.
My experience with Git (the only DVCS I’ve used so far) has been positive. I use it for MvcContrib and for working on the manuscript for ASP.NET MVC 2 in Action.