Git Along Thar Little Dogie

I heard an interesting comparison between distributed and centralised version control systems recently, made by Dan North, “Agile troublemaker, developer and originator of BDD” (BDD is Behaviour-Driven Development and worthy of a column in its own right).

I guess Dan’s main thesis is that the interesting version control stuff with change set algebras and the like is taking place in the distributed world rather than the centralised world (take a look at darcs, perhaps, here) – although he also made the good point that centralised is just a special case of distributed anyway.

Dan was making a persuasive case for git and github collaborative coding against Subversion’s “centralised, monolithic repository” – but he rather left me feeling that Perforce, which I’ve always liked, is doing a pretty good job of managing distributed development with a centralised tool, in the commercial software space.

Of course, Subversion may just be “growing up” and the old commercial version control tools have supported change sets and distributed workforces for ages (although some may be rather clumsy about it, because they utilise a centralised repository approach and were originally architected for a rather different world, than that Perforce, say, was built for).

And, Dan points out, there are things he can do with a genuinely distributed version control tool he can’t do with Perforce: “a working set is not full repository,” he says, “and I can’t commit/diff/log/etc. disconnected from the server; I can’t share changesets with another peer without going via the server; the central server has to sit somewhere, which means everyone who isn’t colocated with it will suffer the laggy connection; it supports a master <--> master replication model, but this is an out-of-band sync (like database replication) rather than using the same mechanisms as client <--> server commits”.

One issue, it seems to me, is that centralised management always feels more comfortable to managers. However, according to Dan, the distributed approach is more effective in practice (centralised controls are often easy to avoid; while distributed controls force people to take responsibility for doing it right). Nevertheless, don’t overestimate the cultural changes needed – especially for management – if you move from a centralised to a distributed environment.

One issue with git in particular may be that, while it suits the likes of Linus Torvalds and the Linux kernel developers, ordinary mortals may find it hard to get their heads around. Dan points out that mercurial SCM offers an alternative approach: “git confronts the user with this complexity, whereas mercurial is intuitive to people familiar with subversion, and still provides much of both the distributed and the changeset-oriented goodness”.

As with concepts like relational algebra and UML (especially Object Constraint Language), change set algebras probably are, or should be, best seen as a powerful enabler for an IDE dealing with the files and releases that programmers understand.

Of course, the positive side of git’s association with the Linux developers is that if it can cope with the complexity of Linux kernel development, it can probably cope with anything you’ll ever meet.

This workshop was a joint event run by the BCS Configuration Management SG (Specialist Group) together with the BCS Open Source SG. It was a useful networking event with wine and snacks as well as a presentation – well worth attending (you can find more of these meetings here. I’m not going to repeat Dan’s presentation; hopefully the slides etc. will be up at http://www.bcs-cmsg.org.uk/ soon.

Since this event was attended by real IT practitioners, I was quite pleased to meet someone there who’d read our configuration management book and who seemed to like it – at any rate, he wanted Shirley and me to autograph his copy. My publishers – BCS The Chartered Institute for IT – tell me there’s a 15% discount offer on the book until the end of November, for readers of this blog, if you enter the promotional code ITSMF10 when checking out of the BCS’s online bookshop.

SHARETweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Pin on PinterestDigg thisShare on RedditShare on TumblrShare on StumbleUponEmail this to someone

David Norfolk is Practice Leader Development and Governance (Development/Governance) at Bloor Research. David first became interested in computers and programming quality in the 1970s, working in the Research School of Chemistry at the Australian National University. Here he discovered that computers could deliver misleading answers, even when programmed by very clever people, and was taught to program in FORTRAN. His ongoing interest in all things related to development has culminated in his joining Bloor in 2007 and taking on the development brief. Development here refers especially to automated systems development. This covers technology including acronym-driven tools such as: Application Lifecycle Management (ALM), Integrated Development Environments (IDE), Model Driven Architecture (MDA), automated data analysis tools and metadata repositories, requirements modelling tools and so on.