[00:05] <jelmer> mwhudson: we need a better story for dealing with batched imports
[00:05] <jelmer> mwhudson: bzrlib should just have a base class that takes care of regular repacking, etc
[00:10] <mwhudson> jelmer: please put your thoughts on https://bugs.edge.launchpad.net/launchpad-code/+bug/559678 :)
[00:10] <mup> Bug #559678: incremental import does full repack 3 times <code-import> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/559678>
[00:14] <thumper> the import is going well though...
[00:19] <jelmer> mw	will do
[00:23] <jelmer> mwhudson: iwll do
[00:27] <jelmer> argh, lagggisch \
[00:28] <jelmer> thumper: it's still a lot slower than a local import
[00:28] <jelmer> thumper: that should be fixed once we start caching Tree objects
[00:49] <thumper> when will we start caching Tree objects?
[00:51] <mwhudson> the currently running import is way slower
[00:51] <mwhudson> i think strawberry is a vm slice though, so that might be a factor
[00:54] <jelmer> thumper: when jam finishes his pack collection refactoring
[01:41] <dhastha> Need help: An error occurred during a connection to translations.launchpad.dev.
[01:42] <dhastha> SSL received a record that exceeded the maximum permissible length.
[01:42] <dhastha> (Error code: ssl_error_rx_record_too_long)
[01:44] <rockstar> dhastha, are you using trunk?
[01:54] <dhastha_> rockstar, yes i asked trunk. I restarted apached. now its working
[02:53] <lifeless> mwhudson: jelmer: repacking should already be incremental only
[02:53] <lifeless> jelmer: you're probably overriding / changing something.
[02:53] <lifeless> fetch knows how to incrementally repack imported packs only.
[02:54] <jelmer> lifeless: I'm doing manual commit_write_group calls every 1k revisions
[02:54] <jelmer> lifeless: I'd like that logic to be in bzrlib rather than the individual plugins
[02:54] <lifeless> jelmer: where the code is is orthogonal to whatever bug you have
[02:55] <lifeless> why is it doing a full pack 3 times?
[02:55] <jelmer> lifeless: I don't know why it's doing 3 repacks, I just see repacks regularly during imports
[02:56] <lifeless> it should incrementally pack, not full repack
[02:56] <jelmer> lifeless: I don't know if it does a full or incremental repack
[02:56] <jelmer> it doesn't seem like a full repack to me, but it might be different for mwhudson
[02:56] <lifeless> 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] <jelmer> 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] <lifeless> jelmer: after 10 write groups, bzr will autopack anyway.
[03:10] <lifeless> jelmer: I think you should be less agressive about triggering a manual pack
[03:10] <lifeless> the only things you will get major benefit from packing are those things that have never been packed.
[03:10] <jelmer> lifeless: I'm only triggering a pack after all revisions have been fetched and I specify the gathered pack hints
[03:11] <lifeless> jelmer: yes, I get that. its still more agressive that needed, I suspect
[03:12] <jelmer> 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] <jelmer> lifeless: rather than optimizing the fetchers in bzr-git/bzr-svn and bzr-hg independently
[03:12] <lifeless> jelmer: I'm not arguing for or against code placement.
[03:12] <jelmer> lifeless: I realize that
[03:12] <lifeless> jelmer: its a distraction in this discussion
[03:12] <jelmer> I guess my comment probably isn't very relevant for this bug
[03:12] <lifeless> which is, after all, on the weekend.
[03:13] <lifeless> 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] <lifeless> 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] <jelmer> I might have a look at that at some point
[03:19] <lifeless> so what I'm suggesting is
[03:19] <lifeless> you do something like (if not hint.was_repack: hints.add(hint)
[03:19] <lifeless> rather than your current simple 'add the hints together'
[03:21] <jelmer> thanks
[03:21] <jelmer> My brain clearly has stopped working so I'm getting some sleep, way too late here
[03:22] <jelmer> gnight
[03:22] <lifeless> gnight
[18:50] <jml> 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] <sidnei> jml, appended to my todo. :)