[00:05] mwhudson: we need a better story for dealing with batched imports [00:05] mwhudson: bzrlib should just have a base class that takes care of regular repacking, etc [00:10] jelmer: please put your thoughts on https://bugs.edge.launchpad.net/launchpad-code/+bug/559678 :) [00:10] Bug #559678: incremental import does full repack 3 times [00:14] the import is going well though... [00:19] mw will do [00:23] mwhudson: iwll do [00:27] argh, lagggisch \ [00:28] thumper: it's still a lot slower than a local import [00:28] thumper: that should be fixed once we start caching Tree objects [00:49] when will we start caching Tree objects? [00:51] the currently running import is way slower [00:51] i think strawberry is a vm slice though, so that might be a factor [00:54] thumper: when jam finishes his pack collection refactoring [01:41] Need help: An error occurred during a connection to translations.launchpad.dev. [01:42] SSL received a record that exceeded the maximum permissible length. [01:42] (Error code: ssl_error_rx_record_too_long) [01:44] dhastha, are you using trunk? [01:54] rockstar, yes i asked trunk. I restarted apached. now its working [02:53] mwhudson: jelmer: repacking should already be incremental only [02:53] jelmer: you're probably overriding / changing something. [02:53] fetch knows how to incrementally repack imported packs only. [02:54] lifeless: I'm doing manual commit_write_group calls every 1k revisions [02:54] lifeless: I'd like that logic to be in bzrlib rather than the individual plugins [02:54] jelmer: where the code is is orthogonal to whatever bug you have [02:55] why is it doing a full pack 3 times? [02:55] lifeless: I don't know why it's doing 3 repacks, I just see repacks regularly during imports [02:56] it should incrementally pack, not full repack [02:56] lifeless: I don't know if it does a full or incremental repack [02:56] it doesn't seem like a full repack to me, but it might be different for mwhudson [02:56] unless either a) you call pack(), or b) you insert a fetch stream with a differing serialiser (and that would be incremental using the pack hint) [02:59] lifeless: basically I'm gathering the pack hints for all write groups I commit (every 1000 revisions) and then specify that list of pack hints to target.pack() [03:00] * jelmer clarifies his comment [03:09] jelmer: after 10 write groups, bzr will autopack anyway. [03:10] jelmer: I think you should be less agressive about triggering a manual pack [03:10] the only things you will get major benefit from packing are those things that have never been packed. [03:10] lifeless: I'm only triggering a pack after all revisions have been fetched and I specify the gathered pack hints [03:11] jelmer: yes, I get that. its still more agressive that needed, I suspect [03:12] lifeless: The fact that after 10 write groups bzr autopacks anyway is one of the reasons why I'd like to see a helper in bzrlib that can take care of determining how often to create write groups [03:12] lifeless: rather than optimizing the fetchers in bzr-git/bzr-svn and bzr-hg independently [03:12] jelmer: I'm not arguing for or against code placement. [03:12] lifeless: I realize that [03:12] jelmer: its a distraction in this discussion [03:12] I guess my comment probably isn't very relevant for this bug [03:12] which is, after all, on the weekend. [03:13] I suspect we need to change the pack hint definition slightly so you can tell if its the pack you added, or a packed version of same/similar. [03:14] if you wanted to do that, I don't think there are backwards compat implications, as its currently defined as an opaque hint [03:18] I might have a look at that at some point [03:19] so what I'm suggesting is [03:19] you do something like (if not hint.was_repack: hints.add(hint) [03:19] rather than your current simple 'add the hints together' [03:21] thanks [03:21] My brain clearly has stopped working so I'm getting some sleep, way too late here [03:22] gnight [03:22] gnight === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [18:50] sidnei, I've just submitted two really simple patches to zope-dev. Could I tempt you into landing them & maybe even releasing the respective components? [22:23] jml, appended to my todo. :)