What is up with these version control systems that use plugins to do everything? I understand that having an extensible system is very useful if users want to create something custom. Mercurial and Bazaar both support plugins written in Python, while Git has an extensive set of commands that allow you to easily write custom scripts in any language.
However, being able to extend a program is not an excuse to ship a product missing features. One of the things that makes Git powerful is that it ships with a lot of capabilities built in.
Take Bazaar for example. If you want to commit only part of the changes in a file, you need the BzrTools extension. To rebase revisions you need the Rebase extension. You need extensions to show diffs in colour, to push all branches at once, and even to remove untracked files in your working tree! Why aren’t these included by default? Are they afraid a user might be afraid to see a coloured diff? Or is it too much work to support these tools directly?
This exactly the problem with plugins: it separates the functionality from the main program. Who is going to install some weird plugin on some website to gain functionality? Who created the plugin anyway, can it be trusted as much as the program itself? How is it updated? What if there’s an incompatibility between the plugin version and the program version? What if I’m using some feature, but others that I’m working with can’t do the same, because they don’t have the plugin installed yet?
Having an extensive set of tools shipped by the program isn’t a bad thing, it’s good. It allows you to use the same workflow and suggest the same solutions to everybody else, without requiring a certain plugin. It also makes features easier to use, as you don’t have to manually install something first.
Git is easily capable of supporting its full feature set release after release, and keeps adding useful features. When upgrading, you can be sure that all your previous commands are still usable. As they are integrated into the system, you can be sure that they get the same amount of attention as anything else.
This last point is more important than you might think. After all, you’re talking about your source code here. You want the program that you use to be reliable, to work consistently across releases. You don’t want to depend on something that you don’t fully trust.
Relying on plugins is just a way for lazy programmers to maintain less code. I really prefer Git’s builtin tools more than some lousy plugin that doesn’t even have it’s own website. If you stick to only core functionality, at least be the fastest ;).
7 comments:
Exactly. A couple of weeks ago I tried to evaluate how good Bazaar's bzr-svn plugin is as an Subversion client. I still don't know because I couldn't get it working due to some dependency problems. Seems like I have too old Python version (or something). It also seems that bzr-svn needs different repository format than the default one in bzr. Doesn't sound like a "works by design" approach to me. And I was just trying to evaluate the tool.
Yes, plugins are nice for users for hacking minor personal convenience improvements but there's a real problem if anyone's workflow starts to rely on some functionality only provided by third-party plugins. Then it's clear that the core tool is lacking some important features.
On the other hand we have success stories of Firefox extensions, Perl CPAN modules, Emacs packages,... Both Bazaar and Mercurial provide semi-official directory of plugins.
"On the other hand we have success stories of Firefox extensions"...
...but see also Coding Horror: The Dark Side of Extensions by Jeff Atwood (from March 18, 2008)
Actually, Mercurial has official built-in plugins. See Extensions bundled with Mercurial.
The notion of a plugin (or extension) exists in order to decouple the core functionality and stuff which is either peripheral, optional, or even cosmetic. Even the Linux kernel has modules you know :-)
@Last anonymous:
Sure, they might be included, but the point still stays, as you have to activate them first. If it's just for Mercurial developers to separate stuff, why not activate them by default? Having to activate plugins gives a sense of of doing something that is not fully supported, just like going to Mozilla with your FireBug problems.
The kernel may have it's modules, but as an end-user you don't have to see them, as you use a distribution that manages all that stuff for you.
Well then your distribution can also manage Mercurial extensions for you :-) How many people install Mercurial from the original download site (excluding Windows people, but for them there is even a custom exe with some stuff enabled)?
Also, I think extensions can harm ease-of-use if they are all enabled by default. For example, "hg help" on a vanilla install will give you the set of core commands. If you add e.g. mercurial queues, and perhaps a couple of other extensions, the list of commands will be much more crowded.
Endly there are extensions like "highlight" (syntax highlighting in the Web view) which are preferably disabled by default as they eat a lot of resources.
Who's going to install them, you ask? For most of those, the answer probably includes the typical Windows user: going by "bzr plugins", mine (2.1.1) came with:
* bzrtools 2.1.0
* explorer 1.0.1 (Bazaar Explorer)
* launchpad 2.1.1 (in-tree)
* netrc_credential_store 2.1.1 (in-tree)
* news_merge (in-tree)
* qbzr 0.18.4
* rebase 1.0.2
* svn 1.0.2
* upload 1.0.0dev
* xmloutput 0.8.7.dev
I don't recall if the default was to install all of them or not, but it certainly wasn't discouraged at all.
Now if only Cygwin had even half of these plugins packaged (not counting the in-tree ones)...
It certainly would be nice if there was more integrated documentation and a websites each could belong to, but oh well. The decent subversion integration & UI were all it took to win me over :-).
Post a Comment