[00:08] Launchpad uses Bazaar 1.17. [00:08] grats [00:13] jml: yay [00:18] lifeless: I think I may've missed something - where would that be necessray? [00:19] mwhudson: hi [00:19] jelmer: test suites ask the test result whether to stop [00:19] to allow aborting a run early [00:20] mwhudson: It was interesting to finally see the lp code :-) [00:20] mwhudson: I noticed a trivial thing that could be fixed, lp:~jelmer/launchpad/default-rich-root [00:20] * jelmer looks again [00:21] jelmer: oh i suspect i didn't fix that because it would actually downgrade all the bzr-git branches now [00:21] mwhudson: it would only affect new ones, but that's a good point.. [00:22] jelmer: if it's the change i think it is, not true [00:22] launchpad rollout issues, full attention in a bit :) [00:23] * SamB wonders where launchpad is rolling to [00:25] mwhudson: it's this change: http://bazaar.launchpad.net/~jelmer/launchpad/default-rich-root/revision/8303 :) [00:26] jelmer: http://bazaar.launchpad.net/~jelmer/launchpad/default-rich-root/annotate/8303/lib/lp/codehosting/codeimport/worker.py#L65 [00:26] jelmer: also, congrats, that's probably the first launchpad branch from a non-canonical LP dev that I've seen :) [00:28] mwhudson: ahh, sorry [00:28] jelmer: np, the comment is misleading [00:28] jelmer: also the code should probably be changed to do a reimport rather than an upgrade for the brisbane-core transition [00:29] mwhudson: yeah [00:36] morning all [00:36] hi Ian [00:40] mwhudson: why reimport? [00:40] mtaylor: perl! [00:41] lifeless: (a) quicker probably (b) the packs imports have squashed commit messages [00:41] lifeless: muah! [00:44] lifeless: question on "best" way to figure out a specific chunk of bzr data... I have a local branch... how do I find the GCA between the local branch and the submit branch? (like, the rev from which a revision bundle would start) [00:45] there's the ancestor: revspec [00:47] mwhudson: will it get the same revids? if so, and the root conversion isn't identical to the conversion logic, then its a problem [00:47] lifeless: yes [00:48] lifeless: they're in rich root already [00:48] mtaylor: as mwhudson says. do you want command line or python? [00:48] mwhudson: ok, if they are already rich root its fine [00:48] lifeless: i'm only talking about bzr-git imports here [00:48] lifeless: not cscvs ones [00:48] mwhudson: converting from packs should be faster than a reimport btw [00:48] for bzr-git [00:48] ? [00:48] I'd expect so [00:48] anyway, the fidelity is the real reason [00:48] mwhudson, lifeless: ah - sorry - irc client misbehaved. command line [00:49] lifeless: last I checked an import from git is faster than an upgrade [00:49] jelmer: thats surprising [00:49] mtaylor: do you want the revid or revno? [00:50] mtaylor: there is --show-base to some commands [00:50] lifeless: well, I think both would eventually be nice ... but revid would be probably more useful [00:54] lifeless: on the other hand, if I need to use bzrlib to do this, I can live with that [00:54] mtaylor: so, for the specific case of where a bundle will start at [00:54] I think its [00:54] bzr revision-info -r submit: [00:55] mtaylor: also, perl! [00:56] lifeless: upgrade seems to be a lot better now [00:57] lifeless: unscientfic tests: bzr-git 8s, upgrade 5s [00:58] lifeless: that gives me ... hrm. [00:59] lifeless: that just gives me my head revision [00:59] * mtaylor looking further... [01:01] poolie: good morning. [01:01] hello spiv :) [01:01] hello lifeless, all [01:02] hi poolie [01:02] Hi poolie [01:04] lifeless: so, I think revision-info is giving me the right thing from one perspective- I think it's giving me the GCA of the local branch that it shares with the remote... [01:04] lifeless: but what I want is the GCA in the context of the remote branch... [01:04] oh wait [01:04] lifeless: nevermind... /me smacks self in head [01:06] jam: ping -- want to review my inventory-delta branch? [01:18] When you do a merge, is the revision that is used to get .BASE the same for all files, or can it be different? [01:18] by default the same [01:18] but there are options that can make it different [01:19] Like a different merge type? [01:19] yah [01:20] Is it the same with --lca? [01:26] so ... how come "bzr upgrade" to --rich-root-pack or --2a seems to go nearly to the end of the progress bar pretty quickly, but then stay near the end for a long time ? [01:26] I'm not sure garyvdm [01:26] SamB: Possibly incorrect phases, or that a single logical step has more work to do [01:27] lifeless: I need to investigate that for something I'm doing for qbzr, and figure how I'm going to handle --weave... [01:27] [#################\ ] Copying content into repository.:Transferring revisions [01:28] lifeless: As allways - Thanks for the pointers [01:28] * SamB wonders what causes the bar to stop spinning [01:28] ask instead what makes it spin at all [01:34] hello lifeless [01:36] 6611.394 Auto-packing repository , which has 15 pack files, containing 15000 revisions. Packing 10 files into 1 affecting 1000 revisions [01:42] lifeless: thanks. Raised as bug 403272 [01:42] Launchpad bug 403272 in bzr-fastimport "bundled hg-fastexport exception re changelog.count" [Undecided,New] https://launchpad.net/bugs/403272 [02:11] * garyvdm is writing a reply to "Nubee question" [02:11] what was that Pyrex alternative? [02:11] Cython? [02:11] yes [02:15] hello [02:16] is there a command to rename a bzr branch [02:16] ? [02:17] JoaoJoao: typically "mv oldname newname" on your filesystem does the trick :) [02:18] JoaoJoao: or is this a branch on launchpad? [02:25] spiv, that doesn't work when I'm using shared repos + lightweight checkouts [02:36] JoaoJoao, there isn't a command for that: it's a bit of a pain [02:37] hmmm looks like mv + bzr switch --force could do the trick [02:38] JoaoJoao, give it a try. [02:38] JoaoJoao, what I do is: mv ~/repos/project/old ~/repos/project/new; echo -n 'file:///home/jml/repos/project/new/' > ~/src/project/old/.bzr/branch/location; mv ~/src/project/old ~/src/project/new [02:38] yes, switch --force should help [02:38] thanks jml, mwhudson [02:40] btw, does bzr support or has some plugin for interactive commits? [02:40] theres a plugin I believe [02:40] also the qbzr commit dialog can select bits [02:49] yup, bzr-interactive works fine :) [02:49] bzr plugins rock [02:50] If you have 2 branches, with the same file-id's, but no common ancestor, how do you merge? [02:51] nvm - bzr merge ../dev2 -r -1..0 [02:52] garyvdm: uhm, probably you want 0..-1 [02:52] ah [02:53] any estimated release date for bzr2? [02:53] * fullermd admits to mild curiosity as to what -1..0 will DO... [02:56] * igc lunch [03:15] Please can someone read this:http://paste.ubuntu.com/225619/ I want to make sure that the advice I'm giving this guy is good. [03:15] http://paste.ubuntu.com/225619/ [03:16] abentley: around? [03:22] * garyvdm sends mail [04:04] * SamB wonders how jam runs the tests for pymemdump [04:13] hi [04:13] How do I tell bzr to ignore committing a file? [04:13] I mean... not to commit a file that was changed. [04:15] GungaDin: there is an option "-x" or "--exclude" for commit [04:15] bzr ci -x [04:15] or just specify files that you wanna commit [04:20] sure thx [04:56] lifeless: kinda around. [04:57] * SamB wanted to file a bug against pymemdump for not having a name and then realized it'd need to have one for him to do that ... jam! [04:57] abentley: I mailed the list [04:57] abentley: copied to you [04:57] lifeless: I see it. [05:01] lifeless: I'm not deeply opposed to PreviewTree.inventory, but I thought omitting it would help us explore what's needed to go inventory-free. [05:02] abentley: I think it has helped us do that [05:05] http://fishbowl.pastiche.org/2009/07/22/a_letter_to_my_younger_self/ [05:06] nice === cprov is now known as cprov-zzz === mordred_ is now known as mtaylor [07:28] garyvdm: if you're around, and jelmer: too; I'm looking [well, I *will be*] looking for a GUI progress bar [07:29] I want to pop up a little progress bar in the bottom right of my desktop. [07:29] pointers appreciated [07:32] lifeless: http://bzr.pastebin.com/d7c92d84a <- just adding a plain Reconfigure class [07:33] i don't want to tease apart the existing code for now [07:36] poolie: sure; I don't think you should tease it apart. The only concern I have is that this makes the module be mixed in style, which muddies things more. [07:36] poolie: I will let you be the judge of how important that i.s [07:43] Incremental steps to a better style is probably better than adding more code to an unwanted style. [07:50] spiv: as long as its really clear to other folk coming along that this is the trend [07:51] spiv: without clarity its just unclear ;) [07:53] lifeless: agreed [07:53] lifeless: pydoc debug is documented to 'Run the test without collecting errors in a TestResult' [07:54] that might be something you'd want to call from inside a debugger i guess... [07:54] poolie: yah [07:54] i'm disappointed that it doesn't remove my bugs :) [07:54] poolie: its a underdeveloped aspect of te interface [07:54] lifeless: lp:~jameinel/qbzr/progress [07:56] lifeless: If you want, I can hack up a minimal plugin. [07:56] bbl [07:57] garyvdm: oh, its not bzr [07:57] garyvdm: its for subunit [07:59] lifeless: Then this diff is a good sample: http://bazaar.launchpad.net/~jameinel/qbzr/progress/revision/813 [07:59] thanks [08:00] How do I check a log given a rev id? [08:13] spiv, btw lifeless said you might have fixed something recently to make tests rm their working directory as soon as they finish? [08:13] GungaDin: bzr log -r revid:blah [08:14] Hmm, I don't remember fixing anything like that very recently. I did make some change about six months ago maybe. [08:16] spiv, also it should have a smiley when reporting 0 vfs :) [08:16] as this pull just did :) [08:16] :) [08:45] jml: jelmer: http://paste.ubuntu.com/226322/ feedback sought [09:15] * igc dinner [10:31] I love comments like "# XXX: Update this after 0.10 is released"... [11:36] igc: I have time to look at the sphinx users docs in ~1.5 hours if that's ok [12:20] LarstiQ: cool [12:23] 'evening Ian === mrevell is now known as mrevell-lunch === cprov-zzz is now known as cprov [13:23] igc: done [13:23] LenZGr_: did you see the bzr-svn 0.6.3 announcement, and was that helpful for your packaging? [13:31] LarstiQ: Yes, thank you! 0.6.3 should be available shortly (I commited it already, but made a mistake which caused the build to fail) === mrevell-lunch is now known as mrevell [13:34] I'm looking for a good way to create archived backups of my repositories. I don't want to backup unless I need to, so I was thinking about parsing "bzr info -v" and using the "revisions" under "Repository:", and use the revision number in the file name. That way I can check if the revision is backed up already. Is there a problem with this? [13:44] LenZGr_: good, that makes me happy :) [13:46] DaffyDuck_: there shouldn't be that many files, so why not let rsync do it's job? [14:13] LarstiQ: The data needs to be encrypted and stored on external media. We're not fooling around when it comes to backups. [14:15] even if you encrypt it, it should still be stored efficiently by your backup software. so backing up an unchanged bzr repo again should not be a problem... [15:17] DaffyDuck_: as Raim said, I'd expect the backup software to be able to detect changes. Other than that - [15:18] DaffyDuck_: in theory revisions could be removed, in practice they probably only get added. How serious about the backups are you? === nevans1 is now known as nevans === nevans1 is now known as nevans [16:12] igc: hi [16:12] hi bialix [16:13] igc: can we disable bugmails in bzr-explorer-dev mailing lists? [16:13] I've got 2 copies of those mails [16:13] one from LP and another from ML [16:14] bialix: you might be subscribed separately? [16:14] I don't understand [16:14] the people notified list on some of them was 'bialix + Bzr Explorer Devs' [16:15] on all of them actually [16:15] I'm trying to disable bugmails on bugs page [16:16] bialix: go for it [16:16] ok, will see how it will going [16:16] bialix: I'm not sure how to do it fwiw [16:16] https://bugs.launchpad.net/bzr-explorer/+subscribe [16:17] I was under impression you explicitly subscribe ML to receive bugmails, no? [16:22] bialix: I can't see anything in the ml or team configuration re that. Ask on #launchpad maybe [16:24] igc: can you explain your comment: https://bugs.launchpad.net/bzr-explorer/+bug/393615/comments/6 please? [16:24] Ubuntu bug 393615 in bzr-explorer "Initialise shared repository hangs [Windows]" [Medium,Triaged] [16:24] what's fixed in 1.18? [16:28] jam: hey [16:31] bialix: bug 394227 [16:31] Launchpad bug 394227 in bzr "bzr init sometimes fails to complete and saturates cpu" [Medium,Fix committed] https://launchpad.net/bugs/394227 [16:32] hi spiv [16:34] jam: If you are inclined to review my updated inventory-delta patch, that would be lovely :) [16:35] jam: I also heard that you were surprised to hear that inv-delta streaming was much better than IDS over localhost HPSS? [16:36] jam: try comparing bzr push -r2000 of bzr.dev into a "bzr init bzr://localhost/ --1.9-rich-root" -- I found ~7.5 min real time vs. 31 min, and much less memory consumption and IO too. [16:36] spiv: I was, though there are ways to explain it. [16:36] mostly in the marshalling/unmarshalling overhead [16:37] As in, 30M transferred vs. ~740M. [16:37] spiv: Not a 2a format? [16:37] spiv: also, I've always focused on "pull/upgrade" and not "push" [16:37] not sure if that matters here [16:37] jam: that would be interesting too, but I thought I'd measure something simpler. [16:38] I wouldn't expect it to affect IDS, it might affect streaming but probably not. [16:38] (the difference between pull/upgrade vs. push, that is) [16:38] Anyway, the current patch reinstates IDS for local fetches. [16:39] my bigger concern ATM is why things are breaking [16:39] Given that IDS is known to have pretty bad performance on the network that seems like the best compromise to me. [16:39] is it a bug that already existed that you are now testing [16:39] or did something break with the new changes [16:39] The test failure I reported? [16:39] yes [16:39] I'm pretty sure it's an existing bug. [16:40] I extended the test coverage significantly. [16:40] That particular test is more precise in verifying that it can actually stream the revisions now, and I also added several new scenarios to the parameterisation. [16:41] It may be that IDS is actually broken for local stacked branches, but even if so my branch isn't a regression there. [16:41] It *might* shed some light on some of our bug reports, though. [16:42] It may be worthwhile extracting the part of the patch that extends per_interrepository's scenarios, and it's test_fetch module, trying it on bzr.dev, and perhaps landing it directly. [16:43] Maybe with a KnownFailure if it really does uncover an existing bug. [16:44] I'm pretty confident that my changes would not have introduced it, the refactorings I did to IDS to make its code reusable by the streaming path were fairly simple... but I've been wrong before :) [16:45] jam: I *think* the issue may be that the tests in bzr.dev don't test any rich-root -> rich-root IDS paths. [16:45] jam: only non-rr -> rr. [16:46] just to verify, the only way to run bzr serve and allow only some users write access is to leave it read-only but have the ones with write access use bzr+ssh, correct? [16:46] spiv: weird [16:46] your review request is in the "other" category [16:46] Maybe because of how you resubmitted it? [16:46] (I was having trouble finding it) [16:47] jam: oh, weird. [16:47] It didn't have any "requested reviews" [16:47] jam: I guess that's possible, just changed the "status" to "resubmit". [16:47] especially not of 'bzr-core' like the other ones [16:47] I fixed that [16:47] Probably a UI bug for launchpad-code reviews [16:47] Which I thought was the way to resubmit, but perhaps not. [16:47] Yeah. [16:48] spiv: I think it *is*, with the caveat of about 3-4 bugs I've opened on it so far :) [16:48] jam: so, I see this bug in bzr.dev [16:49] jam: if I add 6RichRoot->2a to the interrepo scenarios and run interrepo.*test_fetch.*stacking.*2a I see the failure. [16:49] jam: needless to say, my inv-delta streaming code passes that test ;) [16:50] Hmm, or rather, I see a failure, not necessarily a valid failure now I look at it. [16:50] This failure is why I changed the assertion to "can stream these revisions" rather than directly checking for inv parents in the repo. [16:51] Because things seem a bit different in 2a... [16:52] spiv: so the inventory roots should be present in 2a formats [16:52] (as should all the chk pages underneath) [16:52] which is what we had worked on with the "get_stream_for_missing_keys()" a while back [16:52] "can stream" might be a stronger assertion because of the need for child chk pages... [16:53] jam: ah, but it does still fail the "can stream" check. [16:53] spiv: so it is very likely that IDS doesn't fill in parent inventories into a stacked branch [16:53] as the only code that does 'get_stream_for_missing_keys()' is the. .... streaming code :) [16:53] stacking [16:53] the bane of my last few months [16:54] really, it breaks all sorts of things. Especially when coupled with the "RemoteRepository" are not actually stacked anymore... [16:54] Yeah, I know what you mean! [16:54] so the abstraction we put in, is removed, and then everything is exposed again [16:55] "AbsentContentFactory" bugs etc. [16:55] yep [16:56] So, the bug is in bzr.dev; I have fix ready to go, just merge my patch and disable IDS ;) [16:56] jelmer: didja file the bug in the end? [16:57] spiv: I actually thought IDS was disabled when stacking was involved [16:57] but I guess that is more it is disabled when the formats are identical [16:57] In doing the timings of streaming vs. IDS over localhost I did fix one performance bug, btw. [16:57] (in streaming, that is) [16:57] spiv: btw, my loopback can stream 700MB in about... 1s [16:57] There's almost certainly a fair bit of low hanging fruit there, performance-wise. [16:58] so I doubt that is a specific cause of slowdown [16:58] probably the serialization/deserialization is, though [16:58] Right, but my disk can't seek back and forth that fast, particularly when bzr is pushing the disk cache out of memory... [16:58] With IDS, -Dmemory reported VmPeak of 333840. [16:59] vs. 126328 for inv-delta. [16:59] (and VmHWM and VmRSS had similar ratios) [16:59] spiv: I'm curious if you just tweaked the size of the internal cache, how much effect that would have [16:59] (batch_size, and one other flag IIRC) [17:00] So, if you can bzr push -r2000 of bzr.dev over localhost with IDS in 1s I'll be impressed :) [17:01] Possibly the overhead of 103958 HPSS calls started to matter? [17:01] It was certainly reading back a lot of the data it had already written (in addition to the regular repacking over the wire). [17:01] spiv: Right, I'm saying the cost of marshalling/serializing 700MB was important [17:01] not the fact that it was 700MB [17:02] over the loopback [17:02] Sure. 700MB over any other network interface is pretty important, though :) [17:03] spiv: so 4519 is your latest, right? [17:03] That inv-delta was so much faster, even though it's paying CPU cost on both sides (and I don't have dual core), is a good sign for streaming I think. [17:03] jam: yep [17:04] spiv: but time 'bzr branch x y' and compare [17:04] jam: interesting, IDS and inv-delta were much much closer in time on -r1000 [17:04] spiv: very little interesting in bzr.dev pre 1500 [17:04] that is where we got merging support [17:04] (-r1000 is only 1102 revs, -r2000, is 7410 revs) [17:04] 1-~1500 are all just simple commits by martin [17:05] hm... maybe that changed with some of our history mutations [17:05] As in, within 20% rather than over 4x slower. [17:05] there is a mainline history switch with robert as a committer [17:05] Obviously it's many more revs and larger trees, but it's still seems disproportionate. [17:06] (hmm, about 10x more data in knit pack format) [17:06] spiv: computing inventory deltas is generally O(N^2) [17:07] spiv: so what to do about the 'bloat' factor? [17:07] as in, taking 400+MB on disk, rather than <100MB? [17:07] I think the 2a sink needs to be smarter. [17:08] (possibly the smarts should be builtin to the generic sink, rather than making a 2a specific sink...) [17:09] i.e. do a pack midstream if a certain volume of records has been received, on the assumption that can probably save significant disk space. [17:09] Kinnison: not yet, I forgot about it :-) [17:09] spiv: I'lll at least argue that perhaps the source can stream the content in a more efficient manner [17:09] Currently the StreamSink is smart enough to do that at the end, but that's a bit late. [17:09] jam: Is there any situation in which an InventoryEntry could have a symlink_target that is None ? [17:09] jelmer: *pout* [17:10] jelmer: How can I be anything less than the most important person in your life? [17:10] Yeah, that seems likely too, but tweaking StreamSink is likely to be easier. [17:10] * Kinnison sobs [17:10] jelmer: I believe InventoryEntries from a WorkingTree.inventory are set to None, because we want you to go read the symlink directly [17:10] I'd also love to make the stream resumable while we're on the topic ;) [17:10] But the branch is already pretty large! [17:10] Kinnison: :-) [17:11] Kinnison: I'll do it now, while I have my mind on bzr [17:11] jam: ah, thanks [17:11] spiv: so IDS does a repack every 1k revs or so, is that possibly the extra data you were seeing over the wire? [17:11] jam: In that case bzrlib/export/dir_exporter.py should possibly special case that situation? [17:12] jelmer: perhaps. I don't really know what export w/ a workingtree as a source is really meant to mean [17:12] jam: it's some, but not all of it. [17:13] jam: even when it's not repacking I see an enormous number of readvs. [17:13] In fact, I suspect repacking isn't even a majority of the traffic. [17:13] jam: it's done in bzr builddeb, which allows you to build based on either the current working tree or a historic revision. [17:14] jelmer: I'm not really 100% familar with the code. But building from an uncommitted tree seems foolish [17:14] jam: Since it has a tree object around as well I'll change it to use tree.get_symlink_target [17:14] jelmer: tree.get_symlink_target would be the safest bet [17:14] ~740M of traffic for 27M of packs isn't accounted for by repacks every 1k when there's only 7410 revs. [17:14] jam: It's pretty common to not commit until you've tested that building the package works [17:15] spiv: except the size on disk *before* repacking is probably a bit larger? [17:15] I guess you are testing with --1.9-rich-root [17:15] jam: this target is 1.9-rich-root, though. [17:15] which doesn't change much [17:16] Right. [17:16] so... currently testing your code and it is "hung" [17:16] as expected [17:16] Yeah, it has some long pauses :( [17:16] and, as someone else mentioned [17:16] it pauses at: [17:16] [###################/] 14218KB 94KB/s [17:16] which looks like it is almost done [17:16] when in reality, it has barely started [17:16] Two parts where it has long pauses, I think. [17:17] spiv: any idea why we don't even get transport progress updates? [17:17] One where it's busy doing lots of generate_root_texts » _find_root_ids » iter_rev_trees (judging from sampling backtraces with SIGQUIT) [17:17] are you computing all deltas at once? [17:17] (if only SIGQUIT worked on windows...) [17:18] Then another pause after it's sent the full stream and is waiting for the server to respond. Apparently the server does some lengthy work at end of stream. [17:18] (check references, find missing keys?) [17:18] spiv: neither of those should be minutes... [17:18] repacking? [17:18] Although in fact I noticed during that pause for the server that it the pack file in the upload dir was slowly growing. [17:19] Which seems odd, I would have expected it to have spooled out to disk as it was received. [17:19] spiv: converting inventory deltas to full inventories? [17:19] adding them to the repository as fulltext [17:19] and recomputing a "knit-delta" [17:19] Hmm, not a repack on after a single insert into 1.0-rich-root I don't think. [17:19] would be my guess [17:19] Yeah, that could well be it. [17:20] I assume applying deltas is faster on 2a? [17:20] spiv: faster than --1.9-rich-root, most likely [17:20] fast as you would think... not always [17:20] finding minimal deltas helped a lot here [17:20] Well, I'm used to that :) [17:21] The streaming code currently makes a delta against every parent and chooses the shortest to send. [17:21] spiv: so I noticed that you are still using Inter1and2Helper... which means we have to re-read all the inventories. is that correct? [17:22] Yes, probably. [17:22] I think that maybe we can improve that... [17:22] spiv: why is the api: [17:22] _stream_inventories_as_deltas(..., fulltexts=??) [17:23] seems a bit strange to ask for fulltexts when you want deltas [17:23] spiv: so here is *my* summary with mysql-525 [17:23] jam: get_stream_for_missing_keys also generates inv-deltas. [17:23] "time bzr branch" [17:23] real 3m20.731s [17:23] "time bzr IDS push bzr:///" [17:23] real 3m45.805s [17:23] jam: but we don't want missing "compression" parents, we want "fulltexts" at that point. [17:23] "time bzr IDelta push bzr:///" [17:23] real 9m40.311s [17:24] jam: so that flag causes it to generate deltas from an empty revision. [17:24] jam: an alternative that doesn't work would be to send a fulltext inv in the native format [17:25] jam: that doesn't work because the sink expects the inv in the *source* serialisation, but gc formats don't have a functional inv serialisation. [17:25] spiv: well they do after I finish my patch to the bundle code [17:25] jam: (they actually try to serialise as xml5, which doesn't support rich-roots, but looks like they do if the rich-root version is the revision...) [17:25] but stuff like accidentally inheriting from a non-rich-root capable xml inventory serializer needs to be fixed [17:26] So I thought that given that I just defined a format-independent serialisation I should just use that :) [17:26] spiv: I have a patch which fixes that sort of thing :0 [17:26] I agree [17:26] just can't do it for bundles just yet [17:26] Right. [17:26] spiv: I would probably recommend not using 'fulltexts' as the flag, as I find it confusing, I'll see if I can come up with a better name. [17:26] I agree that part of the code is a little unclear, feel free to mention that in your review :) [17:26] Thanks! [17:27] spiv: and I would recommend retrying with --2a as the target. I think that may be a major difference between what we are seeing. [17:27] Yeah, I will. [17:27] spiv: I noticed that you don't delta against revisions you haven't sent... I'm wondering if that is optimal [17:27] (I also have high on my todo list trying the blackbox hpss acceptance tests with 2a to make sure the hpss call counts don't regress) [17:27] consider "bzr push" is just adding 1 rev to a branch [17:28] it will have to extract and send the whole inventory [17:28] Yeah. It was a cheap way to avoid having to figure out what inventories I could depend on the remote having. [17:28] spiv: code like this is der very bad: parent_inv = from_repo.get_inventory(parent_id) [17:29] as in, you re-extract every inventory at least 2x [17:29] actually 3x for rich-root conversion [17:29]