Re: Revision control

[Ivan Shmakov]

>>>>> Arne Babenhauserheide <arne_bab@web.de> writes:

 >> Would there be support for moving to a different revision control
 >> mechanism? Anything is far better than cvs, especially if it's
 >> distributed.  I saw there was some talk of this a while ago but
 >> nothing happened. We've got lots of good options to pick from that
 >> we know will scale well.

 > I like the idea.  It would lower the barrier to begin coding on the
 > hurd (I think), and it would be a good opportunity to clean up the
 > cvs chaos a bit (so newcomers don't get completely lost in the
 > different repositories).

[...]

 > But I don't code, so I don't think it's my place to decide, and the
 > wiki already uses git anyway (even though I prefer Mercurial myself,
 > since it feels more natural to me and doesn't have to be cleaned up
 > regularly - and it works in my Hurd installation :) ).

        Since Git stores the changes changeset-wise, it's easy to use a
        common disk storage for several related repositories.  One may
        test this feature by, e. g., cloning a local Git repository and
        then checking the total disk usage of the repositories:

$ git clone /repository/location /clone/location 
...
$ du -sc /repository/location /clone/location 

        The total disk usage for the two repositories will typically be
        less than the doubled disk usage for any one of them.  (As the
        implementation is based on ``hard links'', both the original
        repository and the clone must reside on the same filesystem for
        the disk space saving to take effect.)  As the project evolves,
        the disk space saved by the technique will become more and more
        significant.

        Also, it's possible to use a related local repository as an
        additional source for changesets while cloning a remote
        repository over the network, allowing for the bandwidth saving
        as well.

        Unfortunately, the technique like this seems to be quite hard to
        accomplish with a file-wise changes storage scheme as
        implemented by Mercurial.

        Also, as Mercurial records only the parents of the revisions
        (and not all their ancestors), it should become challenging to
        implement the ``cherry-picking'' feature.  (Though I don't
        really know any good implementation of it except for that in GNU
        Arch.)

        In general, I'd prefer Git as the DVCS for Hurd.  Alas, I'll
        hardly have any spare time to dedicate to the Hurd development
        in any foreseeable feature.