[RFC] ztransport plugin

Alexander Belchenko bialix at ukr.net
Tue Jan 10 00:06:46 GMT 2006


I'm working on plugin to create transport with transparent 
gzipping/ungzipping weave files. I named it ztransport.

Background:
1) I have dial-up internet connection. *It's definitely my personal 
problem*. But when I need to pull some bzr.dev branch -- it every time 
very hard work. Each time when I need actually pull new revisions bzr 
download inventory.weave that have size of more than 2.5 MB. Plus 
additional weaves for changed files. It's very hard. Especially when 
connection breaks during pull.
2) I have not much free space on my site. *It's definitely my personal 
problem*. But sometimes people ask me why I not publish my working 
bzr.dev branch. Main problem is I have poor internet connection. So 
frequent upload changed weaves (at least inventory.weave that have size 
~2.5 MB) is hard to me.

As I say it's all my personal problems.

I'm thinking about this and one day I try to compress .bzr directory 
with zip. Result was very encouraging: size reduced down to 4 times. And 
weave files was compressed very well. Because most of them have big size 
and regural structure.

So I start to write plugin to check my idea to compress weaves on the 
fly when I do push/pull operations. I wrote first draft version of 
ztransport plugin that working with local transport. Simply to check my 
idea. This transport use raw prefix 'zfile://' that simply stripped off 
in constructor of ZLocalTransport class (inherited from LocalTransport).
In .put and .get methods I do transparent gzipping/ungzipping all files 
with names that endswith('.weave'). It's simple and dirty hack simply to 
check my idea.

After pushing my bzr.dev branch with this plugin I got this numbers:

pushed 3094 revisions (this number showed on progress bar during copying)

pure push (with LocalTransport):
	push duration:	35 minutes
	size of resulting .bzr dir:	20504215 bytes
	size of resulting .bzr/weaves dir:	16297167 bytes
	size of resulting .bzr/inventory.weave file:	2544162 bytes

push with 'zfile://' as destination:
	push duration:	48 minutes
	size of resulting .bzr dir:	4872308 bytes
	size of resulting .bzr/weaves dir:	2708340 bytes
	size of resulting .bzr/inventory.weave file:	530843 bytes

Overall compress ratio is about 1/4. And for inventory.weave this is 
about 1/5.

And reweaving each weave each time during pushing consuming much more 
time than gzipping/ungzipping weaves each time. So I think my experiment 
was successful.

The best thing with this approach is full support by this transport both 
gzipped and ungzipped weaves transparently (but probably not so fast as 
LocalTransport).

I want to create analogue ztransport for HttpTransport. But using 
modified transports with prefixes like 'zfile://' or 'zhttp://' is bad 
idea. Especially with regard to my previous post about bug with 
'file://' prefix handling.

So I think it worth to extend my plugin with zpush/zpull/zbranch/zmerge 
commands. One more: push command store last push location in main bzr 
configuration dir in branches.conf file. But pull use location from 
.bzr/parent file and prefix 'zfile://' is lost (probably because 
transport.base store path without zfile-prefix).

I'd like to hear some suggestion about improving existing ztransport and 
future ZHttpTransport. What you think about z-prefixed urls or paths 
(zfile/zhhtp) and z-prefixed command?

If in the future I will publish my branch with gzipped weaves is this 
will not to be ugly or unusable for others?


And BTW, you could branch ztransport plugin here:

bzr branch http://bzr.onembedding.com/bzr.win/plugins/ztransport

--
Alexander




More information about the bazaar mailing list