[00:02] mtaylor: its the older form of shelve [00:03] mtaylor: for folk with old shelves they need to get ack [00:09] Or for people on Windows, right? [00:21] Hi - I'm getting an error trying to commit which is quite weird. [00:21] http://paste.ubuntu.com/202463/ [00:21] Could not acquire lock "/home/garyvdm/qbzr/wd/qbzr/.bzr/checkout/dirstate": (11, 'Resource temporarily unavailable') [00:22] There is nothing that I am aware of that could be holding a lock. [00:22] Nothing running that is. [00:24] Ah - never mind - I had a bzr runinng in my ide that was stoped in pdb that was holding the lock. [00:27] hello [00:31] jam, thanks for the analysis of 390745 [00:38] jml/thumper/mwh: I'm thinking about doing "reconfigure --stacked-on" or --unstacked soon [00:39] robert questions whether this is a good use of time or not [00:39] any opinions? [00:39] poolie: YES PLEASE [00:42] k [00:42] poolie: how would that interact with LP? [00:43] morning [00:43] hello igc [00:43] thumper: um [00:44] hi poolie, thumper [00:44] poolie: as in, reconfiguring a stacked LP branch [00:44] hi igc [00:44] it would work over hpss to let you configure branches to be either stacked or unstacked [00:44] not sure what you're asking [00:44] poolie:would it pull the necessary revisions from the stacked branch? [00:44] poolie: how about the ability to override the suggested stacking branch? [00:45] yes, it would potentially copy a lot of data when making the branch standalone [00:45] poolie: is incremental reconcile very hard? [00:46] lifeless estimates several days [00:47] thumper: its tricky; gotta copy some data exclude others while simultaneously altering it [00:48] I'd say that is more important than playing with stacking right now [00:48] IMHO [00:48] or [00:49] some optimisations for reconcile on 2a formats [00:49] we're wanting to move more internal teams to the 2a format [00:49] and james_w's ubuntu branches [00:49] ok, that's useful feedback [00:50] though it's not necessarily either/or [00:50] heh [00:50] no [00:50] we want everything, and a pony [00:50] in that i'd need to page in a lot of robert's state to do renconcile [00:50] delicious ponies. [00:50] but i can do the stacking thing fairly quickly [00:51] reduced swapping is always a win [00:51] I'd still like the ability to tell the bzr client not to stack no matter what LP suggests [00:51] which we can't do right now [00:52] the streaming fetch bug is highest IMO [00:52] reconcile is a pain, can't merge for lp developers is a blocker [00:52] other teams have /way/ fewer devs per branch, which makes transition much easier. Also smaller history. [00:53] yeah [00:53] +1 on streaming fetch [00:54] lifeless: as in inventory deltas, or do you mean something else? [00:54] i was assuming reconfigure --unstacked/--stacked-on wouldn't be especially hard [00:54] me either [00:54] spiv: https://bugs.edge.launchpad.net/bzr/+bug/390563 [00:54] Ubuntu bug 390563 in bzr "absent factory exception from smart server when streaming 2a stacked branches" [Critical,Triaged] [00:54] so easy a manager could do it [00:54] poolie: :) [00:54] poolie: also a definitive "don't stack" flag should be easy too right? [00:55] mwhudson: the library call to change already takes care of fetch; more problematic is making a new repo when making a shared repo branch into a stacked branch [00:55] thumper: don't stack may require smart server verb changes. FWIW [00:55] thumper: but is a don't stack flag needed ? [00:55] lifeless: I thought we decided a while ago that stacking was determined entirely client side [00:55] so, seriously [00:55] i have to make some calls today [00:56] thumper: I know the lp-code team have occasion to use it for testing, but outside that group? [00:56] i was hoping i could do one or the other of them in the time i do have today [00:56] lifeless: for unrelated branches, it is useful [00:56] although, perhaps limited use [00:56] poolie: pick one an do it! [00:56] :) [00:56] thumper: /may/ require verb changes ;) [00:56] thumper: we have more verbs doing more things, now. [00:57] lifeless: is one "JFDI" ? [00:57] for a small hack, I'd most like to see network activity not overwriting stuff when there is no progress bar. Or something like that. Its a very visible ugliness [00:58] lifeless: it's high on my list too [00:59] mwhudson: the bzr log from codehosting [01:00] mwhudson: is it safe to attach to the bug, or do you think there are things we'll want kept secret in them ? [01:00] lifeless: i think it's pretty unlikely there's anything sensitive in there [01:04] poolie: ready for a call soon? [01:04] Yep, pushing 2a -> 1.9rr over hpss isn't very fun. 22 seconds, while 2a -> 2a is 6. [01:05] (For 11 revisions of loggerhead.) [01:05] igc, yes, let me get a couple of things closed here [01:05] will call you in 5? [01:05] Still usable, of course, but it doesn't make dogfooding very fun. [01:07] sure [01:07] Peng_: indeed [01:09] Well, I could upgrade lp:loggerhead to 2a when nobody's looking, and it would take them a while to figure it out... :D [01:09] I wouldn't [01:09] not till we fix the current set of critical bugs [01:10] What is the current set of critical bugs? [01:10] Absent factory, IDS being used for push, ? [01:12] lp knows :P [01:22] Yeah, that's mostly it, aside from some rich-root upgrade issues. [01:25] The other one is cross-format inventory delta streaming. [01:26] thats needed for cross format pushing to be pleasant [01:49] igc https://edge.launchpad.net/bzr/+milestone/2.0 [01:49] Peng_: that url for you too [01:49] spiv: what are you up to today? Could I request https://bugs.edge.launchpad.net/bzr/+bug/338561 ? [01:49] Ubuntu bug 338561 in bzr "calling an unknown method logs noise (do_end, and a backtrace)" [High,Confirmed] [01:49] lifeless, spiv, can you tell me about bug 390563 too? [01:49] Launchpad bug 390563 in bzr "absent factory exception from smart server when streaming 2a stacked branches" [Critical,Triaged] https://launchpad.net/bugs/390563 [01:51] poolie: I'm investigating it at the moment [01:51] poolie: all I know for sure is in the bug [01:51] I think [01:51] poolie: Oh, thanks. [01:57] lifeless: hmm, I could have sworn I fixed that a couple of months back. Sure, I'll look at that. [01:58] spiv: lots of them in ~/.bzr.log on lp codehosting ;) [02:00] spiv: could be that someone unfixed them [02:00] or that the fix somehow got lost before being merged... [02:01] SamB: thats what we have tests for; and lp/bb both track merge status by revids [02:01] SamB: e.g. 'no' ;) [02:02] poolie: is there more you want to know about 390563? [02:02] lifeless: depending on how forgetful you are [02:02] and/or whether you actually manage to write said tests [02:03] SamB: it's possible that I actually just fixed something similar but not quite the same, too :) [02:03] SamB: my memory of things I did a few months ago tends to be pretty hazy. [02:03] spiv: yeah, there's also that [02:03] spiv: a few months ago, at my place, we looked at it and said 'lets file a bug and keep going on streaming' [02:06] lifeless: ah [02:07] Also, I think before that I fixed a similar issue to do with streaming bodies, perhaps. [02:07] yes, that rings a bell [02:21] er [02:21] pqm seems to be getting absentcontentfactory errors with two non-stacked branches [02:23] mwhudson: details? [02:23] mwhudson: push or pull [02:24] could be bug 365615 [02:24] Launchpad bug 365615 in bzr "Random 'AbsentContentFactory' object has no attribute 'get_bytes_as' errors with CHK repository" [Critical,Fix released] https://launchpad.net/bugs/365615 [02:24] lifeless: merge, i expect, i don't really know details [02:24] mwhudson: who does [02:24] dunno [02:24] lifeless: all i'm going in is failure mails to the launchpad list [02:25] it could be 365615 i guess [02:25] a traceback would be nice... [02:35] igc: Nice timing results... [02:36] fullermd: indeed. jam rocks! [02:36] 's almost enough to make me wanna see how long importing ports would take... [02:37] Though I don't think I'd want my system murdering me in my sleep for doing so. [02:37] (I'm guessing his chk-map tweaks made a huge difference, together with his faster-commit stuff) [02:37] fullermd: for *really* huge imports, there's still plenty of tuning to do I think [02:38] fullermd: but probably in fast-import itself, more than the core [02:38] fullermd: and I'm unlikely to get to tuning fast-import till after 2.0 reaches RC [02:38] Yeah. It'd be pretty huge. Say around 200k revisions of 200k files. [02:39] (well, files and dirs) [02:42] fullermd: doit [02:43] fullermd: generate a stream and save to disk ; then you can import incrementally or some such [02:44] Yeah, the first step would be seeing if I have enough disk space to hold the fast-import stream... [02:44] Certainly no time for it this weekend though; it's Field Day. [02:45] (and the following few days will be "desperately catch up on sleep", as usual ;) [02:45] whats a field day? [02:46] http://www.arrl.org/contests/announcements/fd/ [02:47] lifeless: does the nightly ppa contain the autopack fix yet? [02:47] (For some of us, hanging around an IRC channel about a version control tool just ain't nerdy enough, see...) [02:49] thumper: I don't know [02:50] ok [02:50] lifeless: a pack of an already mostly packed 2a repo is taking quite a while [02:50] is that expected [02:50] ? [02:50] like 10 minutes [02:52] thumper: do you have the C extensions? [02:53] lifeless: it is from the PPA so I think so [02:53] thumper: and 'pack' has to recompress all history, so its a slow command to run (which is why you shouldn't ever run it unless you have specific reasons to do so) [03:02] thumper: so why were you packing? [03:03] testing mainly, making my repo smaller, considering how to handle this on a large scale for LP [03:06] thumper: bzr will pack as needed [03:06] manual packing is generally a bad idea [03:12] mwhudson or beuno: ping [03:21] jelmer: I just tried to diff two local branches which are both branches of remote svn branches [03:22] And bzr died with a missing revision / no such revision error [03:22] Is there any way to figure out, perhaps, where that revision is? [03:22] if anywhere [03:22] this is kind of an open question too, I suppose [03:23] wondering if there's a way to search a repository or a branch for a specific revision ID [03:24] log -r revid:REVID [03:24] igc: did you change fast-import to use _add_text instead of add_lines at least? [03:27] lifeless: ok I think I am screwed :/ [03:28] well maybe [03:28] it's odd [03:28] or cat-revision [03:28] that revision shows up in a branch in another repository [03:28] but does not show up in the same branch in another reposityr [03:29] *repository [03:29] it's clearly a bzr-svn bug [03:29] :( [03:30] actually, it looks like that revision was in a local branch I did not push to subversion [03:30] and have since deleted in the local repository === timchen119 is now known as nasloc__ [03:41] mwhudson & beuno: unping. :) [03:42] Peng_: not-hi [03:44] mwhudson: Heh, nice timing. [03:45] jam: not yet - my figures are still with code calling add_lines() [03:47] jam: hi [03:47] jam: did you get anywhere with the stacking bug overnight? [03:48] lifeless: I did not, other than to not be able to reproduce it locally, but to have the lp branch fail :( [03:49] jam: lftp seems to be working again with lpp [03:49] mwhudson: FWIW, I unpinged you because I decided to send a merge request. [03:49] lp's sftp server, so you can just mirror down the branch [03:49] you don't need all of lp [03:50] Peng_: oh ok [03:54] Peng_: ah, cool in principle at least, haven't read the diff yet :) [03:54] mwhudson: The diff is the part I'm worried about. :P [03:59] jfroy_: hi [03:59] jfroy_: there's been another report of that as well [03:59] jfroy_: I suspect there's a regression since one of the 0.6 releases [03:59] is there anything at al to be done to salvage that revision? [04:00] I suspect push_merged_revision will help [04:00] since it will push merged revisions, even those of otherwise purely local branches I would not otherwise push myself [04:00] (which I do a lot, scratch branch, private feature branch, merge branches) [04:01] jfroy_: until we've figured out what the bug is about, no idea if push merged revisions will help [04:03] I think it will [04:03] the branch nick on that missing revision if from a branch that was purely local [04:03] I suspect that specific revision never got pushed to svn [04:03] so other people, starting from scratch, will have that revision as a ghost [04:04] push merged revision should avoid that situation [04:04] (purely local and since then deleted) [04:06] if you can confirm that is the case, please let me know [04:06] are you using "bzr branch" or "bzr svn-import" to fetch? [04:08] branch [04:08] Is there any documented problems with Novell filesystems? [04:08] no [04:08] jfroy_: I need to get some sleep, again, if you find more info please let me know [04:09] will do [04:09] jfroy_: I hope to put some time into bzr-svn again at the end of the week [04:09] np [04:09] it's not a show stopper [04:12] I get an error about .bzr/branch/lock/[...].tmp/lock, something like that. I think it may be related to big dir names or so. Stupid Novell anyway. [04:15] lifeless: [04:15] >>> import cpuinfo [04:15] >>> cpuinfo.cpuinfo_processor_count(True) [04:15] 2 [04:25] mtaylor: cpuinfo.processor_count(True) would be nicer [04:25] mtaylor: and for nonstrict mode (which scripts will want, [04:25] cpuinfo.processor_count() [04:25] lifeless: indeed [04:26] if you can :) [04:26] lifeless: totally [04:26] mtaylor: don't you need perl first ? [04:26] lifeless: ew [04:26] mtaylor: to be able to use this, I mean? [04:26] isn't your test thingy that checks cpu counts perl? [04:27] lifeless: so - do you have any philosophical or other arguments about various ways to build python extension modules in the context of a larger autotools-run project [04:27] lifeless: yeah. I'll add perl in just a sec [04:27] mtaylor: personally, I hate setup.py being mixed in with autotools [04:27] spiv: ping [04:27] no point taking one half assed build system and mixing *another* half assed one in with it [04:28] thumper: pong [04:28] mtaylor: but, working >> purity [04:28] spiv: I have a local lightweight checkout of a 2a branch [04:28] lifeless: k. I go back and forth on that... because I hate mixing the two - but I also hate telling automake all about python :) [04:28] lifeless: working bitshift purity? [04:28] spiv: bzr info -v tells me it is Branch format 7 [04:28] * mtaylor is confused [04:28] mtaylor: working is more important than purity [04:29] spiv: pushing to LP says: Source branch format does not support stacking, using format: [04:29] Branch format 7 [04:29] lifeless: yes yes. trolling [04:29] spiv: what can I do to help diagnose [04:29] thumper: known bug, lemme get you the number [04:29] thumper: https://bugs.edge.launchpad.net/bzr/+bug/388908 [04:29] thumper: its filed as a bug already [04:29] Ubuntu bug 388908 in bzr "unnecessary stacking upgrade warning with bzr.dev" [High,Triaged] [04:30] ok, thanks [04:30] jam: branch push is complete. [04:30] spiv: I was wondering if it had something to do with the format 6 remote branch format problems [04:31] thumper: what format 6 remote branch problems? [04:31] thumper: no [04:35] * igc lunch (and afk for a few hours) [04:50] lifeless: it would be great if ruby and perl had something like AM_PATH_PYTHON... [04:57] wouldn't it just [05:00] hey, this may be a stupid question, but is there a difference between bzr shelve and looms? [05:03] huge [05:04] mwhudson: loggerhead/main.py should lose the exec bit, right? [05:05] Peng_: i thought i did that, so yes [05:06] mwhudson: Mind if I do it? [05:06] mwhudson: Err, yeah, you did do it. I misread the diff. Sorry! [05:06] Peng_: i just did [05:07] gar, didn't mean to commit that :( [05:07] * mwhudson uncommits [05:07] Oh yay, one of my 2a branches just committed suicide. [05:09] Oh, it was just bzr-search. [05:10] ...Which doesn't really make a difference, because I usually bug lifeless about these sorts of things anyway. :P [05:15] mwhudson: Hey hey, your revision makes bzr-search explode on 2a. :) [05:21] Peng_: hooray [05:23] lifeless: python. ruby. done. [05:23] lifeless: perl next [05:27] Buggy bug filed, FYI -- https://bugs.edge.launchpad.net/bzr-search/+bug/391459 [05:27] Ubuntu bug 391459 in bzr-search "KeyError in _terms_for_file_terms lambda indexing 2a copy of Loggerhead" [Undecided,New] [05:28] "Ubuntu bug"? [05:37] mwhudson: I like 'hi', 'ho', 'ha'. :) Today I used 'Hello' but it felt kind of silly and verbose. [05:44] Peng_: thanks for the bug; will check later [05:46] lifeless: :) === abentley1 is now known as abentley [06:30] spiv, around? want a quick call in a bit? [06:48] bzr-loom crashes, no matter what I do (Debian bug #532947). [06:48] Debian bug 532947 in bzr-loom "bzr-loom: =?utf-8?Q?=E2=80=98loomify?=" [Important,Open] http://bugs.debian.org/532947 [06:48] how can I un-loomify a branch so I can keep working on it? [06:49] bignose: can you branch individual threads out into separate branches? [06:49] poolie: using what command? whatever I do it crashes with the message as recorded in that bug report. [06:50] bignose: I think its all fixed upstream [06:50] bignose: I'm not sure the branch is corrupted; is it possible that you simply have a broken combination of loom + bzr? [06:51] anything's possible. [06:53] so how can I get back to a working state for that branch? [06:54] or, more relevant to today: a branch that has already been working fine with a loom, but is now unreadable as per that bug report? [06:55] if it *is* a damaged loom, you might be able to get the thread tip ids out using hexdump on .bzr/branch/current-loom, and use the python api to fetch content from the repo [06:55] urk. [06:55] I'd just try upgrading bzr-loom first, though... [06:55] if, as I suspect, you just have an incompatible loom, get your loom version matching your bzr version, and it should be fine [06:55] I'll wait for the Debian package to update, then. [06:56] jelmer was asking for help on it [06:56] the "Debian Bazaar maintainers" (listed as the maintainer) have yet to give any response to that bug report, though :-( [06:57] igc, could you post your "IDE Integration..." message on the project blog? [06:57] is this related to the discussion on the Bazaar mailing list, about the systemic problem of plug-ins that *need* to be at the same version, but never *say* that in the corresponding OS packages? [06:58] bignose: loom tries very hard not to be tied to specific versions [06:58] but there have been a few API skews that affected it recently. [07:29] hi all [07:29] hai [07:37] hi vila [07:46] hi Ian ! === afk is now known as mthaddon === maxb_ is now known as maxb [09:23] Does bug #390563 waste disk space in non-stacked branches or just bandwidth? [09:23] Launchpad bug 390563 in bzr "absent factory exception from smart server when streaming 2a stacked branches" [Critical,Triaged] https://launchpad.net/bugs/390563 [09:23] ...S'pose I could check it myself. [09:23] Peng: and tell us if you can reproduce it and how [09:24] Oh, right, I forgot that that bug only affects certain branches. [09:28] effects? eh [09:28] Affects. [09:28] Well, the bug may effect certain branches too, but that would be a really weird bug :p [09:29] Someday, I should learn the difference between those two words. [09:29] Then I should verify "then" and "than". :P [09:30] Generally, affect is a verb and effect is a noun. [09:30] (OK, I just said that one for the punny thing.) [09:30] * Peng_ is obviously a linguistic master. :P [09:31] Oh, you can sort them out. Their knot that hard. [09:34] fullermd: you're a bad man [09:36] mwhudson: Shouldn't that be "your a bad man"? [09:37] Hey, the proof is in the pudding, just take a different tact. [09:54] Hi all [09:54] What's the status of the HistoryHorizon feature currently? [09:55] (The use case I'm looking for is the "Old huge project" mentioned on http://bazaar-vcs.org/HistoryHorizon) [09:56] Is it fulfilled by stacked branches? [09:59] Lo-lan-do: They're not the same thing, but stacked branches let you store the repository on the server, similar to a lightweight checkout, only you've got a real branch. [10:07] Lo-lan-do: we have decent performance and excellent compression even for huge old projects, in the 2a format. [10:17] Users will just move the goalposts by making even huger projects. :P [10:18] lifeless: Huge as in? [10:18] I'm talking about a 16G CVS repo here. [10:19] lifeless: Do you sleep? [10:19] We need to do some cleanup in there, and it'll be smaller with bzr, but still, if the main repo could be limited in history that would certainly help. [10:21] Could the main repo be stacked on a historical one, thus making day-to-day operations fast while keeping history? [10:22] Lo-lan-do: What do you mean? Like, have a stacked branch pointing to another one on the same machine? [10:22] I'm very glad to hear about 2a, too. Do you think it'll be stable before the end of the year? [10:23] Peng_: Yes. So daily commits only add to the smaller "current" repo. [10:23] But maybe 2a entirely removes the benefits of such an approach, in which case I'll happily recommend that. [10:24] hi all [10:24] is there a way to setup a configuration (bugtracker settings) that will be propagated during a bzr branch to all users ? [10:26] Lo-lan-do: Having a larger repo isn't a problem. Stacking that would be pointless. [10:27] Peng_: theory has that I do [10:27] Having to replicate a large repo with file transfers could cause problems. [10:27] Lo-lan-do: that could be massively smaller - perhaps even 1GB total, in 2a [10:27] Lo-lan-do: Actually...a smaller repo would probably save a few ms here and there, but stacking would also cost a few ms here and there. :D [10:27] Lo-lan-do: If the users do "bzr branch --stacked", they won't have to replace the entire thing. [10:27] I fear that smart repo formats wouldn't be very good at rsyncing (but maybe I'm completely wrong) [10:27] Peng_: but its only EOD, not time-to-sleep now [10:27] Err, replicate* [10:28] lifeless: Ah. [10:28] Lo-lan-do: all our formats since pack-0.92 rsync very well [10:28] lifeless: Except when they get packed... [10:28] Lo-lan-do: old data is rarely moved on disk, so it rarely shows up [10:28] Lo-lan-do: as long as noone runs 'bzr pack', which they shouldn't. [10:28] Good to know. [10:29] I guess bzr pack could be run monthly or so, if it's useful at all. [10:29] I wouldn't even do that [10:29] bzr incrementally packs as commits and pushes occur. [10:29] More and more excellent. [10:30] every power of 10 commits it does a full pack automatically [10:30] so if you have 1M commits today, you'd need another 9 million to need another full pack ;) [10:31] Running "bzr pack" occasionally *would* buy you a teensy bit of performance, but it's not enough to matter. Autopacking keeps things from getting out of hand. [10:32] Peng_: actually, full packing when its not needed, with pack ordering, can decrease performance :) [10:32] Peng_: (for a central repo thats only push/pulled with) [10:32] lifeless: Oh? Why? I don't get it. [10:32] Also, Firefox crashed. Arrgh. [10:32] How do the new repo formats cope with thousands of branches? [10:32] Peng_: by creating a single large btree that has to be read rather than a smaller one with the most recent data and a larger one that isn't read at all [10:33] lifeless: Ahh. [10:33] you'd need fairly extreme repos for this to show up [10:33] as we get a 200:1 fanout in our indices today [10:34] Lo-lan-do: should be fine; there isn't a single file listing all the branches or anything, so its much of a muchness [10:34] Good. [10:35] Last two questions: timeframe for format 2a being officially stable? And possibility for repo-side hooks? [10:35] Repositories don't really know about branches. They're just big bags of revisions. [10:35] (The hooks can be done without, they use incron for now) [10:36] (they=my current client) [10:36] Well, I guess it could matter if you had a complicated history and bzr was bad at choosing compression parents, but it's not. [10:36] Lo-lan-do: 2a is supported now; however you need https://bugs.edge.launchpad.net/bzr/1.16/+bug/365615 - we're still polishing the code around the format. [10:36] Ubuntu bug 365615 in bzr/1.16 "'AbsentContentFactory' object has no attribute 'get_bytes_as' errors with CHK repository on write operations" [Critical,Fix committed] [10:37] Lo-lan-do: we'll be doing a 1.16.1 with that hotfix and possibly a couple of others (to do with stacking on 2a formats) [10:37] I'm not in much of a hurry, they'll need time to think about it anyway. [10:38] My current job is to find quickfixes to make the CVS repo a bit more usable than it currently is. [10:38] ...and to provide recommendations for the longer term. [10:38] I'm pretty sure bzr will be in that part :-) [10:39] awesome [10:40] Stupid question: how large is MySQL's repo? [10:40] A bzr branch uses 600 MB (with working-tree) [10:40] Peng_: ~600 megs or so [10:41] The .bzr is 467MB here [10:41] Lo-lan-do: of mysql? [10:41]