[Top][All Lists]

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

Re: GNU Emacs is on Bazaar now.

From: James Cloos
Subject: Re: GNU Emacs is on Bazaar now.
Date: Tue, 29 Dec 2009 15:55:15 -0500
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.90 (gnu/linux)

>>>>> "Óscar" == Óscar Fuentes <address@hidden> writes:

JimC> On a 64-bit box (Linux kernel, GNU userland) the initial branch caused
JimC> the python process to boloon to over two gigs of vm, most kept resident.

Óscar> What version are you using? For me, it required approx 1 GB on a 64 bit
Óscar> GNU/Linux machine. (bzr 2.0.1, python 2.6.4, http)

That one still has an old install of bzr: 2.0rc1.  Python just tells my 2.6.

I'll have to update that one, but I will not try downloading a new
branch; neither side needs to waste the required bandwidth.

Óscar> Branching from the local trunk mirror required ~180 MB for me,
Óscar> using a shared repository.

Agreed; creating a quickfix branch as per the wiki required much less vm.

>> I can imagine that it'll be a significant load on the server, too.

Óscar> With http/sftp, bazaar transfers a lot of data but as it is CPU-bound
Óscar> too, it does not hit the server too hard. The bzr protocol (or bzr+ssh)
Óscar> causes a noticeable cpu load on the server.

I was thinking of vm load, but that was dumb, since bzr obviously does
not run on the server in sftp/http mode.... [SIGH]

Is the VM load an issue in ssh mode, along with the cpu load?

>> How painful is it to grab an additional branch from the main repo over
>> sftp, comared to the grab of trunk?

Óscar> Grabbing and additional branch requires a fraction of the cost of the
Óscar> initial branch. Bzr will transfer only the missing revisions. IIRC it
Óscar> required 22 minutes for the initial branch (trunk) and 4 minutes for
Óscar> multi-tty.

Good.  That is what I hoped for.

I do see that it transfers much more data than it ends up storing on
disk.  A du(1) of .bzr trunk/.bzr is on the order of 200 Megs, but
it (claims to) transfer(s) something like twice that over teh sftp link.

And my first pull since the initial branch only changed 27 files (25 M,
1 +N and 1 -D), created a new pack of 1417748 octets, but needed 5 Megs
of xfer to grab those changes.

I expect that the native protocol is more efficient.

Also, given the note about locking, does creating a branch over sftp
create the kind of lock that was described earlier?  Or does that only
occur when /pushing/ changes to the sv repo?  I used sftp instead of
http even though I am read-only because my last attempt over http
couldn't even max out a DS0 straw, much less a fat pipe.  But I'd hate
to block commiters by doing so.

James Cloos <address@hidden>         OpenPGP: 1024D/ED7DAEA6

reply via email to

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