| 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:05 |
| 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:10 |
| thumper | the import is going well though... | 00:14 |
| jelmer | mwwill do | 00:19 |
| jelmer | mwhudson: iwll do | 00:23 |
| jelmer | argh, lagggisch \ | 00:27 |
| 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:28 |
| thumper | when will we start caching Tree objects? | 00:49 |
| 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:51 |
| jelmer | thumper: when jam finishes his pack collection refactoring | 00:54 |
| dhastha | Need help: An error occurred during a connection to translations.launchpad.dev. | 01:41 |
| dhastha | SSL received a record that exceeded the maximum permissible length. | 01:42 |
| dhastha | (Error code: ssl_error_rx_record_too_long) | 01:42 |
| rockstar | dhastha, are you using trunk? | 01:44 |
| dhastha_ | rockstar, yes i asked trunk. I restarted apached. now its working | 01:54 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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() | 02:59 |
| * jelmer clarifies his comment | 03:00 | |
| lifeless | jelmer: after 10 write groups, bzr will autopack anyway. | 03:09 |
| 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:10 |
| lifeless | jelmer: yes, I get that. its still more agressive that needed, I suspect | 03:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| jelmer | I might have a look at that at some point | 03:18 |
| 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:19 |
| jelmer | thanks | 03:21 |
| jelmer | My brain clearly has stopped working so I'm getting some sleep, way too late here | 03:21 |
| jelmer | gnight | 03:22 |
| lifeless | gnight | 03:22 |
| === 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 | ||
| 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? | 18:50 |
| sidnei | jml, appended to my todo. :) | 22:23 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!