Bill Baxter wrote:
On Wed, Jun 3, 2009 at 3:14 PM, Leandro Lucarella <llu...@gmail.com> wrote:
and because it
supports local branches (I didn't read about how branches are managed in
Mercurial yet, but I understand that Mercurial doesn't support local
branches).
      It does through the LocalBranch extension.
Ok, lots of extensions! =O

This lots of extensions thing does make me nervous.  The idea of
making an SCM pluggable is nice in many ways, but the fact that these
things are not included means you're subject to version
incompatibilities and some plugins working on Unix but not Windows,
and maybe just plugins that aren't QA'ed very well, or plugins that
conflict with other plugins, or competing plugins that do very similar
things but don't work well together.

All this makes me really prefer to get all the key bits of my SCM from
one source.  Then, for instance, I know that that source will consider
it *their* problem if, say, the XYZ function doesn't work on Windows.
I.e. you're less likely to find yourself in a situation where core
devs say the XYZ plugin solves your problem so they won't fix it, but
XYZ doesn't work and the guys that made XYZ have disappeared or happen
not to care about your platform.

Does that make sense?  I feel pretty confident that all the commands
that come with git play nice with each other (or at least the ways in
which they don't are clearly documented).   I feel less so about a
loose confederation of plugins from various sources.

Note that a lot of these "extensions" are maintained by the core Mercurial team and distributed as part of the official Mercurial releases. With git, you have over a hundred executables hidden in the lib folder and only some of them get called depending on the commands you call and the options you set. In Mercurial some of those are called "extensions" and the nice thing is that you are not limited to those that come with the official release.

                Jerome
--
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to