Version Control: Plug-ins vs Toolkits

There’s no such thing as the perfect version control tool and there never will be. That’s why extensibility is #4 on my list of evaluation criteria for VCS tools. There will always be pressure on these tools to enable new ways of working, provide more information for decision making and provide smarter integration with other tools. Over and above that, extensibility is really important for both technical and social reasons.

Technically, trying to ship a tool which is all things to all people creates all sorts of problems particularly w.r.t. reliability, my #1 evaluation criteria. Bloatware takes longer to ship each time, quality typically drops regardless, and the extra features don’t necessarily hit the mark anyway. As Mozilla has shown with Firefox and Thunderbird in recent years, it is far better to produce a rock solid core product that supports plug-ins in a documented way. Done right, the result is higher quality, better performance, and extensions that better meet the needs of the user base anyway.

Socially, a plug-in architecture increases the engagement of the community that grows around successful products. Whether open source or commercial, it takes a community to raise great software and plug-ins let that community scratch their itches in a sanctioned way.

There are different ways of tackling the extensibility challenge but the best way in my experience is by explicitly supporting plug-ins as Bazaar and Mercurial do. Other tools like Git have gone down the well worn toolkit path, and while that’s much better than having a monolithic application, I believe the plug-in path is a wiser one for a host of reasons.

Firstly, toolkit products tend to get extensions and enhancements developed as Unix shell scripts or Windows batch files, reducing their portability across platforms and hence usefulness to the user community. Secondly, scripting needs tend to put a negative pressure on the UI in that a large amount of options begin appearing just for scripts. That only gets scripts so far though, so then the raw files tend to be parsed, making it increasingly difficult over time for those formats to evolve. (Encapsulation isn’t just good theory – it’s good practice.) Thirdly, a plug-in architecture puts a positive pressure on the product designers to have a rich, clean API for plug-in developers. Tools without that pressure are more likely to have internal APIs that expose physical design details instead of logical design ones. Once again, that leads to a fragile product where few are prepared to make desirable changes after a while in case something breaks. Compatibility dominates as a consideration – innovation grinds to a halt.

Of the new breed of VCS tools around, I think Bazaar leads the pack w.r.t. its plug-in architecture. http://bazaar-vcs.org/BzrPlugins lists over 60 plug-ins! And it is easy to write your own as explained here: http://bazaar-vcs.org/WritingPlugins. Mercurial also has a good plug-in architecture with 30 plug-ins listed on http://www.selenic.com/mercurial/wiki/index.cgi/UsingExtensions. Both Bazaar and Mercurial plug-ins can add new commands while Bazaar plug-ins also let you add options to existing commands. Useful stuff.

As well as plug-ins, pre and post command hooks are really useful for integrating VCS tools into your toolset. While Git is lacking in a plug-in architecture, its hook capability looks good and similar in scope to what Mercurial is offering. Bazaar also has a useful set of hooks both in the core and scattered across some commonly used plug-ins. The documentation on these needs some work though, an area sure to receive lots of attention as we push hard towards Bazaar 1.0.

Bazaar 0.18 is now available. Please download it and give the Bazaar team your feedback so we can make Bazaar 1.0 as good as we possibly can. Here is a sample of the Bazaar plug-ins you may wish to try with it:

• BzrTools -a collection of useful extensions
• BzrGtk – a set of GUI interfaces
• BzrSvn – round-tripping to SVN repositories
• difftools -display differences using the tool of your choice
• extmerge – resolve conflicts after a merge using a GUI tool
• dbus – automatically notify team members on your LAN re branch changes.
• and many, many more.

Do you have a favorite Bazaar plug-in? If so, please add a comment below explaining why.