Source control for all dmd source (Git propaganda =)

[Bill Baxter]

2009/6/4 "Jérôme M. Berger" <jeberger at free.fr>:
> Bill Baxter wrote:
>>
>> On Wed, Jun 3, 2009 at 3:14 PM, Leandro Lucarella <llucax at 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.

Yeh, I have to believe that eventually things will settle down, and
all the plugins that prove to be indispensable will be folded into the
Mercurial core.

Similarly I'm pretty sure the remaining issues with Git on Windows
will be fixed before too long.

As for ability to add functionality to Hg vs Git, I'm talking out of
my ass here, but my guess is what you're seeing there with those 100
commands in the Git directory is basically the Git "plug-in API".  It
just happens to be exposed as shell commands, instead of Python entry
points like you find in Mercurial's API.  At least I seem to recall
reading somewhere that Git was designed like Unix, with lots of little
commands that do one specific thing, and higher-level commands built
out of those lower-level commands.

But anyway, I don't think anyone has yet pointed out a single
functionality so far that Mercurial has (in plugin or otherwise) which
Git does not.  So whether or not you can extend Git as easily as
Mercurial may be kind of a moot point.

--bb