[Merge] Slow socket
John Arbash Meinel
john at arbash-meinel.com
Fri Aug 18 15:47:59 BST 2006
Carl Friedrich Bolz wrote:
> I've updated the slow-socket patch once again, I hope it is ok now.
> John Arbash Meinel wrote:
>>> The intention was to have at least _some_ lines which get removed
>>> when the file is changed again, and not just more and more added lines.
>> Okay. I think it is a little odd, but probably fine for manually
>> generated changes.
> I guess the only way to get some realism with this is to actually use a
> tree for an existing project. How about the following (unrelated to this
> merge, just an idea): Put three test-trees (small, medium, big) of
> existing projects into a zip file somewhere on a website and write
> benchmarks that look for these trees (for example in
> bzrlib/benchmarks/example_trees) and run with these trees. If the trees
> are not present, the benchmarks would be skipped.
Interestingly enough, if you use my cache_dir stuff, you can actually
sneak real trees in. Which I've done for 'kernel_like_tree'. I don't
typically run on a real kernel tree, but from time to time I've used it
to see what would happen with a real source. (Usually I just run the
command directly on a kernel source tree)
However, it has been discussed before that we should do something like
this. Have a real tree with real information in it available for the
benchmarks. I think the permutations are a little bit bigger than you
suggest, simply because we probably want the trees in various states.
At the very least we have 2 parameters: size of the working tree, length
For example, in weave format branches, the inventories are all in 1 big
Weave, and weaves scaled as O(N lines). So having a 2K tree with 200
revs was as bad as having a 200 entry tree with 2K revisions (at least
with inventory operations). We've fixed that with knits, but we'll still
have some issues.
Anyway, I'm very positive about having real test data as part of the
benchmarks. (A kernel tree with lots of history gets really big, though)
>> I think 'directory_name' is a little bit long... I use 'root' or 'dest'
>> in other locations. Some might not like my variable names either,
>> though. The only strict requirement is that they be meaningful.
> directory_name is used in existing tree-building functions, so I kept
> that name.
Sure. Aaron used 'directory_name'. For the stuff I worked on, I added
everything with 'root' because 'directory_name' was too long for me.
Like I said, not a blocker, just personal preference.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060818/d67c318e/attachment.pgp
More information about the bazaar