bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Revision control


From: Ivan Shmakov
Subject: Re: Revision control
Date: Wed, 04 Jun 2008 12:55:21 +0700
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)

>>>>> <olafBuddenhagen@gmx.net> writes:

 >> [...] but I'd prefer to see the Hurd development more accessible,
 >> and even though there are many good candidates, Mercurial is best
 >> suited for that, at least in my opinion.

 > How accessible it is, depends first and foremost on what most people
 > know. That probably leaves Mercurial and git as the only serious
 > contenders...

        Actually, there's no point for searching for a ``popular'' tool,
        and I hardly believe that Hurd will be developed by the ``most
        people'' mentioned above.  In my opinion, it makes far more
        sense to ask, who would be those Hurd developers of the future?
        And then, what tool would they know, or would have the
        motivation to learn? what tool would be useful for them to know?

        Well, it seems that the one interested in ``network'' operating
        systems would probably leave Hurd alone (``is there a facility
        comparable to Linux iptables(8), anyway?''.)

        The one interested in secure or proven OS would probably choose
        something like Coyotos at first.  (Yes, there're plans to make
        Hurd run on top of Coyotos, but these are plans, aren't they?)

        For J. Random Hacker, looking for a development environment, GNU
        seems to be the natural choice.  It doesn't matter, whether it
        would be GNU/Linux or GNU/Hurd, though.

        Are the ones interested in the OS kernel development the only
        group which could be interested enough in Hurd to participate in
        its development?  It seems so.

        As for the motivation, hardly one could learn much by learning
        only one of a kind.  I expect that those who're interested in
        free software kernels will dig into several ones.  And then it
        makes the point to learn /both/ Mercurial and Git, since the
        latter is used for Linux development, and the former is used
        for, e. g., Coyotos'.

 > Among those two, git is the one I know myself. My decision for
 > learning git rather than Mercurial was influenced mostly by Xorg's
 > (or in fact Keith Packard's) decision, but also other things like the
 > fact that Savannah offers git hosting but no Mercurial hosting.

 > Once I actually started learning git, I quickly became convinced
 > that I made the right choice. The thing I really like about git is
 > that, unlike almost all other software available today, it really
 > follows the UNIX philosophy, both in concept and in implementation.

 > git, like UNIX, is based on a couple of very simple yet powerful
 > ideas, and a set of basic tools doing the work. On top of that, you
 > get a set of high-level scripts to easily perform all typical
 > operations; but the internals are not hidden behind a limiting
 > interface -- once you understand how things work, you can use the
 > low-level tools to do about anything you can imagine.

        ... And, in my opinion, that contributes to the ``usefulness''
        of knowing Git.  Isn't the intent for Hurd is to be based on
        ``very simple yet powerful ideas''?  And to provide layered
        (rather than monolithic) implementation of its features?

 > Not knowing Mercurial, I can't really judge. But I have a very hard
 > time believing that any other system comes even *close* to the power
 > and flexibility of git... git is not a shiny toy with idiot-proof
 > UI; it's a powerful tool for serious users.

        I should note that I use Mercurial /more/ intensively than Git
        (due to my occasional participation in Scheme48's development.)
        So my judgement of Git's applicability is on a weaker ground.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]