VCS comparison table

[Jakub Narebski]

/me too post ;-)

Sean wrote:
> On Tue, 17 Oct 2006 18:44:11 -0400
> Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> 
> > That can lead to feature bloat.  Some plugins are not useful to
> > everyone, e.g. Mercurial repository support.  Some plugins introduce
> > additional dependencies that we don't want to have in the core (e.g. the
> > rsync, baz-import and graph-ancestry commands).
> 
> Shrug, it's really not that tough to do in regular ole source code.
> On Fedora for instance you have your choice of which rpms you want
> to install to get the features of Git you want.

git-core, git-email, git-arch, git-cvs, git-svn, gitk
(and git-debuginfo).

gitk and gitweb were developed in its own repositories, but some time
ago got incorporated into git repository. We have contrib/ area.
QGit, Cogito, StGit are developed separately.

> > Plugins also don't have a Bazaar's rigid release cycle, testing
> > requirements and coding conventions, so they are a convenient way to try
> > out an idea, before committing to the effort of getting it merged into
> > the core.
> 
> Hmm.. It's pretty easy to test out Git ideas too.  People do it all
> the time, and without plugins.  Junio maintains several such trees
> for instance.  Dunno.. I just think plugs _sounds_ good to developers
> without much real benefit to users over regular ole source code.

Thanks to many low lewel (plumbing in git-speak) commands it is very
easy to prototype (write actually) new command in language suitable
for fast prototyping, i.e. shell or Perl (or Python, too). Then if it is
performance critical, or if it get troublesome to manage shell script
version, it gets rewritten in C as builtin command.
-- 
Jakub Narebski
Poland