[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Revision control
From: |
Ivan Shmakov |
Subject: |
Re: Revision control |
Date: |
Sat, 31 May 2008 01:10:04 +0700 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) |
>>>>> 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.
Re: Revision control,
Ivan Shmakov <=