Re: GNU Emacs is on Bazaar now.

["Óscar Fuentes" <ofv@wanadoo.es>]

James Cloos <cloos@jhcloos.com> writes:

[snip]

>>> 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?

The cpu load on the server is only an issue for the bzr[+ssh]
protocol. I don't know how much VM load the bzr smart server causes
while serving a remote branch operation, but it is worth testing.

>>> 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.

Over the sftp/http protocols, bzr acts very dumb. It needs to read
lots of data for knowing which revisions to grab, etc.

> I expect that the native protocol is more efficient.

The bzr protocol does lots of work that otherwise the client must do if
it were using the dumb protocols, so it is significantly 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.

IIRC someone here said that bazaar supports concurrent r/w access over
http/sftp, which is quite surprising to me as adding info to the history
can touch a big area of the metadata, AFAIK. The report about the lock
issue seems to confirm that bazaar locks the branch (or repository?)
sometimes. I don't know for which operations bazaar locks and if it
locks only writes or reads too.


-- 
Óscar