Re: git copies of cvs modules available

[Arnaud Lacombe <lacombar%gmail.com@localhost>]

On Wed, Jan 13, 2010 at 3:38 PM, Joerg Sonnenberger
<joerg%britannica.bec.de@localhost> wrote:
> On Tue, Jan 12, 2010 at 01:34:54PM -0500, Arnaud Lacombe wrote:
>> > Perhaps this would be the point to note that Mercurial's preferred
>> > remote update service requires only http and a cgi script...
>> >
>> that won't forbid the cgi to take huge resources at all... the "git
>> service" is pretty much nothing but a pipe to git-pack-objects (not
>> sure it's that one exactly, but it's the idea).
>
> It is very easy to provide CTM-like operation for Mercurial in a way
> that requires *no* Mercurial or any other dynamic component on the
> server *and* that is almost as efficient in terms of network bandwidth
> as the native IO protocol.
>
> All you have to do is provide a cron job that memorizes the last
> revision and bundles all newer revision into a file like
> "netbsd-src-changes-20100112-0600.bundle". The cron job also appends
> that revision hash and that filename to "netbsd-src-index.txt" or so.
> The client can now fetch the second file via normal HTTP/FTP/whatever,
> check what files have missing revisions and either fetch the files
> manually to "hg unbundle" or just use "hg pull" with the HTTP URL.
> Bundles are compressed themselve and essentially the same as the wire
> protocol used with the native network protocol, the only additional
> overhead is the index file (small!) and the small script glue around
> that. Add regular full snapshots to make bootstrapping not too much of a
> chase the tip and it is a very mirror friendly system.
>
very interesting... that should be doable with git too, it is just a
matter of generating packs another way they are now, ie incrementally
rather than re-calculating everything every-time. After all, all we
need is for each head all new objects between $client_rev and
$server_rev. How do you handle the granularity between each crontab
run without a mercurial-aware process ?

 - Arnaud