[00:00] <lifeless> moin
[00:00] <igc> hi lifeless
[00:00] <igc> python figures for you lifeless: 346.5MB -> 181.4MB
[00:01] <igc> OOo and mysql still going
[00:01] <mwhudson> oh man, i which this was deterministic
[00:01] <mwhudson> wish
[00:07] <lifeless> mwhudson: which was?
[00:07] <mwhudson> https://bugs.edge.launchpad.net/bzr/+bug/249256
[00:07] <mwhudson> i'm getting somewhere now
[00:07] <lifeless> igc: this is consistent; I am sure it can drop another 50% via the ordering work I had hoped to get done today
[00:08] <lifeless> but sprinting on other more face2face things
[00:09] <ChristopheT> Hi.  I am struggling to write some tests (in tests_http.py) with redirected web servers.  For 2 web servers it is done, but I'd like to test with 10 redirections.  Any pointers?
[00:09] <mwhudson> lifeless: bzrdir.py
[00:09] <mwhudson> line 1021
[00:09] <mwhudson> tree_format = repository._format._matchingbzrdir.workingtree_format
[00:09] <mwhudson> 'repository._format._matchingbzrdir' is the _class_ object
[00:09] <mwhudson> and so 'repository._format._matchingbzrdir.workingtree_format' is the _property_ object
[00:10] <mwhudson> hilarity ensues
[00:11] <lifeless> mwhudson: sweet
[00:12] <mwhudson> lifeless: i think (a) this is priority 0, (b) i'm not the best person to fix it
[00:12] <mwhudson> i guess it's getting late for you though?
[00:12] <lifeless> 0012
[00:12] <tacone> sorry, how to get the last revision (with no .bzr files or stuff like that) ?
[00:13] <lifeless> tacone: bzr export
[00:13] <tacone> and without having to branch millions of revisions ?
[00:13] <mwhudson> lifeless: so i guess you're not the best person to fix it either
[00:13]  * mwhudson pokes poolie, spiv 
[00:13] <tacone> lifeless: bzr export works only when I have already branched, right ?
[00:13] <bob2> tacone: export can take a remote branch url
[00:13] <lifeless> mwhudson: have you merged zr-search loggerhead ?
[00:13] <lifeless> tacone: no, ou can export any branch
[00:14] <mwhudson> lifeless: no, i reviewed it and had comments and then ... someone we know ... screwed up beuno's life :)
[00:14] <lifeless> mwhudson: a certain celebrity?
[00:14] <tacone> bzr export lp:~encompass/memaker/trunk --format=tgz gives: bzr: ERROR: Not a branch: "/var/www/aaaa/httpdocs/"
[00:14] <mwhudson> lifeless: yeah
[00:14] <tacone>  /var/www/... is my current directory
[00:14] <lifeless> mwhudson: ergh
[00:15] <lifeless> tacone: bzr export foo.tar.gz lp:~encompass/memaker/trunk
[00:15] <mwhudson> i can probably make the fixes i requested myself, but it would definitely be quicker easier for beuno
[00:15] <lifeless> (bzr help export should help you)
[00:15] <lifeless> mwhudson: pls don't let it bitrot; thumper confirmed you have work time available at your discretion for this
[00:16] <mwhudson> lifeless: it looks like today is a loggerhead day
[00:16] <mwhudson> (when i can stop worrying about bzr.dev being broken anyway)
[00:17] <beuno> mwhudson, lifeless, I'll try and get to those changes today or tomorrow
[00:17] <lifeless> I have to halt()
[00:17] <mwhudson> beuno: if you can just tell me which parts of the code need to change to do them, that'll probably be enough of a hint for me to be able to do them
[00:18] <lifeless> I'll be doing gc stuff tomorrow; mail me if you have things for my attention, otherwise its headphones on and code away
[00:19] <beuno> mwhudson, I'm wrapping some things up, if I don't fix them, I'll send you the hints
[00:20] <mwhudson> beuno: cool beans
[00:21] <beuno> and sorry for the lag
[00:29]  * mwhudson changes location
[00:31] <tacone> Thanks lifeless, works :-). good night
[00:36] <thumper> I have a switch question
[00:36] <thumper> anyone know that area well?
[00:37] <thumper> There is a shared repo at ~/gnome-bzr/repos/metacity with some branches under it: "devel" and "some-other"
[00:38] <thumper> in ~/gnome-bzr/src/metacity there is a lightweight checkout of ~/gnome-bzr/repos/metacity/devel
[00:38] <thumper> if we are in the ~/gnome-bzr/src/metacity directory, I was told that `bzr switch some-other` would work
[00:39] <thumper> but instead an error is returned: bzr: ERROR: Not a branch: "[stripped/home/tthurman/gnome-bzr/src/metacity/vectacity/".
[00:39] <thumper> damnit
[00:40] <bob2> it should switch to the sibling 'some-other' of the currently bound branch
[00:40] <mwhudson> yeah, i thought that worked
[00:40] <thumper> I was trying to nicely strip the home dir out
[00:40] <mwhudson> new enough client bzr?
[00:40] <thumper> I've asked the user
[00:40] <thumper> ha, he is on 1.3.1
[00:41] <thumper> newer bzr needed?
[00:41] <mwhudson> hardy was released too early
[00:41] <mwhudson> i don't exactly know, but it's a fairly new feature
[00:41] <bob2> 1.4rc1
[00:43] <thumper> bob2: thanks
[00:52]  * mwhudson pokes poolie, spiv again
[01:12] <spiv> mwhudson: hi
[01:13] <mwhudson> spiv: https://bugs.edge.launchpad.net/bzr/+bug/249256 is critical
[01:13] <mwhudson> spiv: please fix :)
[01:25] <igc> ping markh
[01:26] <markh> igc: hi ian
[01:26] <igc> markh: re your cog.py patch, why the 'del sys.argv[0]' line?
[01:26] <markh> IIRC, the new script is sys.argv[0]
[01:26] <markh> so nuking that puts cog.py back in [0]
[01:27] <markh> ie, so cog.py sees the same argv it would without the wrapper script
[01:27] <igc> markh: so python magically self-repairs that dict?
[01:27] <markh> list?
[01:27] <igc> yes, list
[01:28] <igc> ignore that
[01:28] <igc> ok - brain working again :-)
[01:28] <markh> :)
[01:28] <igc> thanks markh :-)
[01:28] <markh> np - thanks for looking at the patch :)
[01:29] <markh> I actually screwed up the patch to the .cog itself, which I need to email about
[01:29] <markh> ie, I used "out1" instead of "outl" in some cases - trailing "number one" versus "letter l" :(
[01:30] <igc> :-(
[01:30] <igc> markh: I'll approve and merge the cog.py patch now
[01:30] <markh> as usual, a bit of a mad rush to clean up the patch before sending it off, then only testing one of the main "branches"
[01:31] <markh> great, thanks.  I've got yet more to come soon, now that I've worked out how to include QBzr in the installer and have tortoise re-use that - but I'm still trying to get my life back into order since europython.
[01:31] <igc> markh: now is a good time to clean things up. 1.6rc1 is pending
[01:31] <markh> igc: were you in dubai?
[01:32] <igc> markh: no. I can't travel just at the moment - health problems unfortunately
[01:32] <markh> bugger - anyting too serious?
[01:32] <igc> markh: how did your Bazaar talk go btw?
[01:33] <markh> well - I think Steve was happy because Chris Withers said that due to my talk he would investigate bzr (I believe Chris and Steve are personal friends?)
[01:33] <igc> markh: things could be better. See http://ianclatworthy.wordpress.com/2008/06/26/how-can-i-help/
[01:34] <igc> markh: did you like steve's talk? it was partly based on a paper of mine
[01:34] <markh> yes, I did alot and I saw reference to your paper which I'm yet to read.  I think its very interesting.
[01:34] <markh> a nice "post xp" methodology
[01:34] <markh> neo-xp? :)
[01:34] <chadmiller> mwhudson: Thanks for filing that bug, #249256 .
[01:35] <markh> post-modernism-in-xp? ;)
[01:35] <mwhudson> chadmiller: i'm trying to encourage someone to figure out how to fix it properly :)
[01:35] <markh> igc: damn - very sorry to hear about your health :(
[01:35] <igc> markh: I doubt my paper will change the world as much as Kent Beck's paper on XP did but one can only hope!
[01:36] <igc> markh: yeah - it's a bummer :-)
[01:36] <chadmiller> mwhudson: I could normally sit on my hands, but a patch from this afternoon is essential for my team.  Grr.
[01:36] <chadmiller> ^patch^patch to bzr
[01:36] <mwhudson> chadmiller: the --weave thing?
[01:36] <chadmiller> Yeah.
[01:36] <mwhudson> chadmiller: let me see if i can hack
[01:38] <mwhudson> hm, maybe it just takes 2 characters :)
[01:45] <mwhudson> chadmiller: this seems to fix it for me: http://pastebin.ubuntu.com/27879/
[01:48] <mwhudson> poolie: ^^
[01:49] <mwhudson> argh
[01:51] <igc> markh: so confirming, you're planning to resubmit your patch on 'optionally install tbzr ...'?
[01:51] <markh> igc: yes
[01:51] <igc> markh: I'm mark it as resubmit
[01:51] <markh> thanks!
[01:53] <mwhudson> oh ffs
[01:53] <mwhudson> my repo on people.ubuntu.com is knits
[01:53] <mwhudson> i thought pushing was taking a while
[02:03] <mwhudson> poolie: http://people.ubuntu.com/~mwh/repos/bzr/create-tree-from-remote-branch-bug-249256/ contains the fix and some changes to the test setup
[02:03] <mwhudson> poolie: but test_selftest fails
[02:05] <mwhudson> chadmiller: any luck?
[02:06] <chadmiller> mwhudson: I haven't tested it.  Sorry -- brain fried.  Need rest now.  G'night.
[02:07] <mwhudson> chadmiller: ok
[02:07] <chadmiller> I mailed my co-worker, who should be waking in not too long.
[02:07] <chadmiller> mwhudson: Thank you!
[02:07] <mwhudson> chadmiller: hope it helps!
[02:07] <mwhudson> thanks for bringing it up!
[02:11]  * mwhudson lunches, biab
[02:48] <poolie> (back)
[02:55] <poolie> mwhudson: i'm merging that not
[02:55] <poolie> now*
[02:56] <poolie> i mean for review, not yet to trun
[02:56] <poolie> trunk*
[02:56] <mwhudson> oh good :)
[02:56] <poolie> did you upgrade it?
[02:56] <mwhudson> well, moved my old repo away and made a new one
[02:56] <mwhudson> so yeah, it's packs now
[02:58] <mwhudson> poolie: i guess the getting of bzrdir format from the tree/repo should be pushed down another layer
[02:58] <mwhudson> (and possibly given a more official sounding name than '_matchingbzrdirformat')
[02:58] <mwhudson> oh and something equivalent should be on branches
[02:59] <rick_h_> lifeless: ping
[02:59] <poolie> and does that branch now pass everything but test_selftest?
[03:00] <mwhudson> poolie: yep
[03:00] <poolie> that patch looks reasonable
[03:01] <poolie> would you like me to look at the selftest failures?
[03:02] <mwhudson> yes, i'm not really sure how to fix them
[03:02] <mwhudson> well, i can see a couple of ways
[03:03] <poolie> i guess it's good this method is specifically tested
[03:07] <poolie> mwhudson: so to state the obvious we need to pass it format descriptions in the form it expects
[03:08] <poolie> i think passing strings to a function-under-test that is meant to get a different type of object
[03:08] <poolie> because it just happens to pass through the current duck-typed implementation is a bit gross
[03:08] <mwhudson> poolie: yes
[03:08] <poolie> or at least, confusing to someone reading the test
[03:08] <poolie> i've updated the formats_to_scenarios docstring a bit too
[03:09] <poolie> sheesh
[03:09] <poolie> or ints even
[03:09] <mwhudson> alternatively you could say that it's a feature of the adapters that they treat the arguments as black boxes
[03:10] <mwhudson> though, pff, that's a bit bogus i think
[03:10] <poolie> um
[03:11] <mwhudson> poolie: i think a stronger argument is that if bazaar is changing so that the bzrdir format is derived from other inputs rather than supplied separately
[03:11] <mwhudson> the test suite should change to reflect that too
[03:11] <poolie> right
[03:11] <mwhudson> the problems of trying to fix bugs on release day :)
[03:12] <igc> spiv: can you take a look at http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C4877E9ED.7020503@gmail.com%3E please? Would to be nice to get this into 1.6 if you're happy with it.
[03:13]  * igc lunch
[03:13] <poolie> mwhudson: i guess it's nice for python interfaces to not be over-particular about the interfaces of objects passed to them
[03:13] <poolie> but the tests should actually adhere to whatever the code under test expects
[03:14] <poolie> mwhudson: i'm going to change it to pass actual formats anyhow
[03:14] <poolie> and see how that looks
[03:14] <mwhudson> poolie: okidoke
[03:15] <spiv> igc: I'll take a look
[03:32] <poolie> mwhudson: something like this...
[03:32] <poolie> http://pastebin.ubuntu.com/27890/
[03:33] <mwhudson> poolie: that does make the tests look more realistic
[03:34] <poolie> it is a little longer to write but fortunately the format objects do already have __eq__ methods
[03:34] <poolie> so with the vfs
[03:34] <poolie> so with the vfs_scenarios similarly changed that one test passes
[04:06] <poolie> mwhudson: ok they're all fixed, i'll send it to the list
[04:06] <poolie> maybe you could read it there?
[04:07] <mwhudson> poolie: okidoke
[04:08] <mwhudson> wow, tcp being useful -- my laptop was asleep in my bag for about 10 minutes there
[04:08] <poolie> nice
[04:08] <poolie> sadly many protocols on top or nat devices now have shorter timeouts
[04:09] <poolie> mwhudson: so do you know what value of "sometimes" causes it to fail?
[04:09] <mwhudson> poolie: no, i'm totally baffled by that
[04:09] <mwhudson> poolie: i can only imagine i wasn't running the code i thought i was
[04:11] <poolie> mwhudson: so i'm just writing the cover letter
[04:12] <poolie> and can you explain to me _why_ you want to change the format list passed to these multipliers
[04:12] <poolie> in some ways passing the bzrdir separately is cleaner
[04:13] <mwhudson> well, because it was passing it separately that allowed the bug to land
[04:14] <mwhudson> and if _every_ callsite is like "(f, f._matchingbzrdirformat)" that seems redundant
[04:14] <poolie> right
[04:14] <poolie> i agree
[04:15] <mwhudson> that's all
[04:17] <poolie> spiv, could you read my submission of mwh's fix?
[04:17] <poolie> or igc
[04:55] <beuno> mwhudson, updating search
[04:55] <mwhudson> beuno: awesome
[04:55] <beuno> should address all your comments, except the last two "optional" ones
[04:55] <beuno> which, well, I promise I'll get to them soon
[04:56] <beuno> :(
[04:56] <beuno> Not allowed here
[04:56] <beuno> Sorry, you don't have permission to access this page.
[04:56] <beuno> You are logged in as Martin Albisetti.
[04:56] <mwhudson> that's ok
[04:56] <mwhudson> !?
[04:56] <beuno> when trying to request another merge from that branch
[04:56] <mwhudson> where's that?
[04:56] <mwhudson> oh ffs
[04:56] <spiv> poolie: ok
[04:56] <beuno> https://code.edge.launchpad.net/~beuno/loggerhead/bzr-search_integration/+merge/480/+request-review
[04:57] <mwhudson> beuno: oh, that's a known bug
[04:58] <mwhudson> beuno: try again, i sneakily changed daniel.bueltmann's subscription
[04:59] <beuno> mwhudson, I replied and approved it instead of requesting another review
[04:59] <mwhudson> heh ok
[04:59] <beuno> I still can't understand the merge request UI
[05:02] <mwhudson> beuno: ah uh
[05:02] <mwhudson> the onblur handling means you can't click on the suggestion :)
[05:03] <mwhudson> because the focus leaves the box, the div disappears, then the click is processed
[05:03] <beuno> damn, I knew it wasn't that easy
[05:03] <mwhudson> (it seems, anyway)
[05:03] <mwhudson> i guess hide the div a few tenths after the onblur?
[05:05] <beuno> mwhudson, good idea, let's try that
[05:05] <mwhudson> the other changes all look fine
[05:06] <mwhudson> beuno: hm, the look if there are no suggestions is maybe a little odd
[05:07] <beuno> mwhudson, right, it should probably say "no results"
[05:08] <mwhudson> yeah
[05:12] <beuno> mwhudson, pushed
[05:15] <beuno> I wonder why we hide the users email, if it gets exposed in the revid anyway...
[05:16] <mwhudson> beuno: the loading div still has different vertical padding to the suggestions
[05:16] <mwhudson> beuno: but i'm not sure i care
[05:17] <mwhudson> beuno: merge and push away!
[05:17] <beuno> mwhudson, thanks  :)
[05:17] <beuno> I promise I'll go back and give the UI some love
[05:17] <beuno> I want it to look more polished
[05:17] <beuno> I'm just a bit exhausted these days
[05:17] <mwhudson> sure
[05:18] <mwhudson> it's definitely good enough to land now
[05:22] <beuno> mwhudson, does LH take some time to update in LP?
[05:22] <beuno> hm, it took a bit under a minute to update my push
[05:23] <mwhudson> beuno: it has to wait for the branch to be mirrored, which can take a minute yes
[05:23] <beuno> lifeless, http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/revision/182
[05:23] <mwhudson> the scanner seems busticated, we're looking at that now
[05:23] <beuno> mwhudson, so you're not doing http anymore?
[05:23] <mwhudson> beuno:
[05:23] <mwhudson> ?
[05:24] <beuno> mwhudson, accessing branches through http
[05:24] <mwhudson> yes
[05:24] <mwhudson> that only requires the puller run
[05:24] <mwhudson> er, and something else
[05:24] <beuno> oh, and those need mirroring too?
[05:24] <mwhudson> but not the scanner
[05:24] <mwhudson> possibly our guts are slightly too visible :/
[05:24] <beuno> right, the scanner I can understand. LH is what I have a hard time understanding why it takes a minute
[05:25] <mwhudson> because when you push over bzr+ssh you're not writing files to the same area accessing them over http reads
[05:26] <beuno> aaaah, ok
[05:26] <beuno> that's something I didn't know  :)
[05:30] <beuno> I'm off to bed
[05:30] <beuno> thanks for the review mwhudson
[05:30] <mwhudson> g'night & np
[05:55] <spiv> poolie: I've reviewed (and approved) that fix
[06:19] <poolie> thanks spiv
[06:47] <jkakar> How do I upgrade a knits repository to packs?  I've just tried running bzr upgrade but it's not happy.
[06:48] <bob2> pastebin the error - 'bzr upgrade' should upgrade you to the default, which is packs
[06:48] <bob2> unless your repository contains branches from svn
[06:48] <jkakar> bob2: http://paste.ubuntu.com/27920/
[06:49] <jkakar> Running bzr upgrade in the repository root results in: http://paste.ubuntu.com/27921/
[06:49] <jkakar> Also, there are no branches from SVN.
[06:50] <bob2> ah
[06:50] <poolie> it's a pretty poor message
[06:51] <bob2> 'branch' is trying to branch from a rich-root-pack repository into your regular pack repository, and giving you a crappy error message
[06:51] <jkakar> Ah, okay.
[06:51] <jkakar> So I need to upgrade to rich-root packs?
[06:51] <poolie> yes
[06:51] <jkakar> Is there any reason I might not want to do that?
[06:52] <bob2> (or branch that jelmer's branch to another repository or standalone branch)
[06:53] <jkakar> Right, thanks.
[06:56] <Peng> Hmmm. Merge conflicts.
[06:57] <Peng> Ohh. I previously merged this branch, backed it out, and then backed out the backout, so that probably has everything confused.
[06:58] <igc> poolie: so I'm good to merge the stacking user doc as is?
[06:59] <poolie> i'm merging it, with the comments on the list
[06:59] <poolie> i'm trying to work out what to do about the thing i replied with
[07:05] <igc> poolie: thanks
[07:05] <poolie> igc, there are two tricky situations at the moment, kind of related to each other
[07:05] <poolie> - branching from a stacked branch
[07:05] <poolie> either within a single repository, or to a new locaiton
[07:06] <poolie> to a new repository
[07:06] <igc> spiv: thanks for reviewing and merging that patch of Adrian's
[07:26] <poolie> spiv/igc, could you have a look at the incremental patch i just posted to the StackableBranch thread?
[07:27] <igc> poolie: sure
[07:34] <poolie> abentley: if that message indicates you're awake you could look at it too...
[07:41] <spiv> poolie: the argument list of assertRevisionInRepository seems backwards, although that's not new in your branch.
[07:41] <spiv> poolie: but it is highlighted by assertRevisionsInBranchRepository, which is the way round that you'd expect :)
[07:41] <poolie> :)
[07:42] <poolie> i can fix that then
[07:45] <spiv> poolie: that patch looks ok to me, although it's the first stacking-related patch I've reviewed :)
[07:46] <poolie> what do you think of the logic of the change, and aaron's comment earlier in the thread
[07:47]  * Talden thinks... Man, with the list of stuff in NEWS already and more stacking, a new indexing model, compression, Win32 FindFirst, ... The next few releases are going to be huge leaps forward.
[07:48] <spiv> I agree that we don't want to create a stacked branch unless the user explicitly said --stacked.
[07:50] <jml> or they push somewhere with a stacking policy
[07:51] <poolie> does python have a system facility to tell you of illegal characters?
[07:54] <spiv> illegal in what sense?  Not encodable to some encoding?
*,;:/|\ that kind of thing
[07:56] <poolie> on windows
[07:58] <spiv> Oh, right.  Illegal in filenames.
[07:58] <spiv> No, there's no good way I know of.
[07:59] <poolie> my question was kindof ambiguous
[07:59] <spiv> Does modern windows still have issues with filenames like "CON:"?
[07:59] <jml> poolie: it's also a little bit more complex on windows
[07:59] <jml> spiv: yes.
[07:59] <poolie> heh
[07:59] <poolie> i don't know if it's still true but at one point even con.doc caused problems
[07:59] <poolie> probably fixed now
[08:01] <jml> I think it's just 'CON', without a colon.
[08:01] <poolie> lifeless: ping?
[08:02] <lifeless> hi
[08:02] <poolie> lifeless: i have a patch up that changes branch so that branching from a stacked branch will not implicitly give you another stacked branch
[08:03] <spiv> See also http://bugs.python.org/issue481171
[08:03] <spiv> Which I filed in 2001 :)
[08:04] <lifeless> poolie: h. was it doing that? sprout, used by branch, would have needed explicit instructions to preserve stacking
[08:04] <poolie> spiv, what is ASX:PRN?  porn.com.au?
[08:04] <poolie> :)
[08:05] <poolie> lifeless: it was doing that, and there was even a test for it
[08:05] <poolie> it might not have been your codeof course
[08:06] <spiv> poolie: heh
[08:06] <spiv> I can't remember why I encountered that bug, come to think of it.
[08:07] <spiv> But it probably was something to do with ASX:PRN :)
[08:07] <poolie> you say so in the bug
[08:07] <poolie> a junior miner apparently
[08:07] <spiv> Oh, right.
[08:07] <spiv> Apparently I can't read my own bug reports :)
[08:07] <poolie> though in 2001 they could well have been both a junior miner and a dot com :)
[08:08] <poolie> glad to see you did take tim's advice and get a real OS :)
[08:08] <spiv> :)
[08:09] <lifeless> poolie: oh it was preserving with a test that it did? hmmm
[08:09] <lifeless> I think perhaps I thought 'bzr branch traunk --stacked local; bzr branch local morelocal
[08:10] <poolie> that cause raises some serious questions
[08:10] <poolie> well, some of which i wrote about
[08:19] <lifeless> I can look at that when I hit the office if you like
[08:23] <lifeless> thumper: lol; irony
[08:36] <pygi> lifeless, poke
[08:37] <lifeless> hi
[08:37] <pygi> lifeless, you have a moment for pm?
[08:38] <lifeless> sure
[08:39] <thumper> lifeless: I fixed the problems with the pqm queue-abstraction branch
[08:39] <thumper> lifeless: and merged that into queue-abstraction-2
[08:40] <thumper> lifeless: the second one will most likely conflict with any other branches
[08:40] <thumper> lifeless: as it moves all the code around
[08:40]  * thumper is away for dinner now
[08:40] <thumper> have fun
[08:41] <lifeless> thumper: well the first conflicted hugely; thats why I put up a branch that resolved it
[08:41] <lifeless> :)
[08:41] <thumper> lifeless: yeah, but I didn't look at yours as you said the tests were failing :)
[08:41] <thumper> mine works :)
[08:41] <thumper> now I'm really gone
[08:41] <lifeless> thumper: nope, I said tests were passing in mine
[08:41] <lifeless> th	they were failing on yours :). have fun
[08:42] <lifeless> I'll cross-compare the two branches today
[08:43] <poolie> lifeless: i'd like to do another beta or rc before i finish today
[08:43] <lifeless> poolie: sounds good
[08:43] <poolie> maybe  i should just merge this
[08:46] <lifeless> this being ?
[08:47] <poolie> the --stacking patch
[08:47] <lifeless> roght, well I'll have it revied for you in < 1 hour; heading to do teeth then walk over now
[08:47] <poolie> also, i need to automatically pick a new format
[08:48] <poolie> so that should give you time to do your stuff
[09:07] <lifeless> ~
[09:16]  * igc dinner
[09:39] <jml> lifeless: Please take a look at https://code.edge.launchpad.net/~jml/bzr-loom/switch-aliases when you get the chance
[09:39] <jml> I'd request a review, but there's a bug in Launchpad stopping me (which I'm fixing now)
[09:39] <poolie> jml, 1.6b3 is up with stacking inside
[09:39] <jml> poolie: sweet.
[09:39] <poolie> :) yum dogfood
[09:39] <poolie> i'm going to log off for a bit
[09:39] <bob2> haha
[09:40] <jml> poolie: I won't be able to land the bzr upgrade for a day or so.
[09:40] <jml> poolie: but will do it asap
[09:43] <lifeless> james_w: jelmer: Odd_Bloke: I'm in bouvet
[10:03] <lifeless> jml: the merge proposal mail should say 'lp:~jml..' don't you think?
[10:04] <jml> lifeless: I didn't get the email I think.
[10:05] <jml> lifeless: I got an exception when I hit submit. Please forward me the email so I can triage appropriately.
[10:05] <lifeless> jml: done
[10:15] <awilkins> jam: Has that fast walkdirs thing been merged into dev?
[10:15]  * awilkins looks
[10:17] <awilkins> Apparently not. I could benefit from that that, I have some monstrous trees here (34,000 files in one)
[10:17] <awilkins> Anyone want a win32 installer of 1.6b3?
[10:28] <Peng> That fast walkdirs thing is for Win32; what's the situation on other OSes?
[10:29] <Peng> Are they already very fast or do they not offer the same APIs or what?
[10:32] <awilkins> Peng: I'd imagine it's already v.fast on Linux ; the 34,000 files tree I spoke of returns a status in less than a second on Linux
[10:33] <Peng> So..this optimization is only necessary on Windows? Ok.
[10:33] <awilkins> Peng: The win32 API is most definitely not the same as Linux VFS
[10:33] <awilkins> Peng: Filesystem performance on Win32 in general is much slower than Linux
[10:34] <awilkins> Peng: But obviously, a lot of the time they are comparing apples to oranges ; code that's performance tuned for Linux vs... the same code on Windows
[10:37] <Peng> Okay.
[10:37] <Peng> Thanks. :)
[10:37] <Peng> Still, are there any opportunities for similar optimizations on other OSes?
[10:37] <awilkins> Peng: I presume you mean "OS/X" ?
[10:37] <Peng> I'm a Linux user.
[10:38] <awilkins> I'm not sure ; I don't know how "close to the metal" the Python implementation of walkdirs is
[10:41] <lifeless> awilkins: its posixish - e.g. slow :)
[10:42] <lifeless> Peng: there is room to improve linux and mac os X yes
[10:42] <Peng> lifeless: Is anyone going to do it, or is it "good enough"?
[10:43] <lifeless> Peng: I hope to be focusing purely on performance and the odd killer-feature over the next 6 monthsw
[10:44] <awilkins> Is there an "eradicated test errors on win32" effort anymore?
[10:44] <lifeless> yes
[10:44] <fullermd> Does that include the bit-o-both that "new inventory stuff so log {-v,$FILE} doesn't make me want to kill myself"?
[10:44] <lifeless> jam is running on win32
[10:45] <jelmer> beuno, ping
[10:45] <awilkins> Well, clearly he's not optimizing win32 for jollies
[10:45] <lifeless> :)
[10:46] <Peng> beuno: This is unrelated to the ping you just got, but now that LH's bzr-search_integration branch has been merged into the trunk, is it done? Should I stop pulling it?
[10:55] <mwhudson> lifeless: bzr-search_integration got merged
[10:56] <lifeless> mwhudson: awesome
[10:58] <mwhudson> well, maybe
[10:58] <mwhudson> i told beuno to merge it, don't know if he did
[10:58] <mwhudson> yeah, he did
[11:00] <Peng> mwhudson: See the question I just asked beuno?
[11:03] <igc> awilkins: the fast walkdirs isn't in bzr.dev yet because it's not fully approved
[11:04] <igc> awilkins: one pyrex file stills needs a review. Do you know pyrex by any chance?
[11:05] <igc> I'd certainly love to see that change make it into 1.6, even though it missed 1.6rc1
[11:06] <awilkins> igc: Alas, I don't really know Pyrex very well. I can confirm it builds on windows though ;-)
[11:07] <igc> awilkins: are you or markh doing the windows 1.6rc1 installer?
[11:08] <igc> I guess we could always consider including it in there if that file gets reviewed in the next few hours
[11:08] <Peng> (1.6b2 -> 1.6b3)
[11:11] <awilkins> jam: Which toolchain are you building that pyx on (mingw or msvc?)
[11:12] <igc> yep, I meant 1.6b3, not 1.6rc1 sorry
[11:12] <igc> awilkins: I believe he is using mingw
[11:12] <awilkins> Hmm, I think there are good reasons to use msvc
[11:13] <awilkins> 1) Python is built with MSVC
[11:13] <jelmer> 'morning igc, Peng, awilkins
[11:13] <awilkins> I suppose it doesn't matter too much depending on how many what your deps are built on
[11:14] <igc> hi jelmer
[11:14] <jelmer> igc, thanks for the review
[11:14] <awilkins> For example, bzr-svn pretty much has to be built on msvc for win32 because it has deps that are msvc flavoured
[11:14] <Peng> jam: With the push-and-update plugin and bzr.dev, as of a few days ago, the "This transport does not update the working tree" message no longer gets swallowed.
[11:14] <Peng> jelmer: Good morning. :)
[11:15] <jelmer> hi Peng (-:
[11:15] <igc> jelmer: np - sorry it took so long. Been less than healthy so my reviewing has been on hold lately
[11:16] <lifeless> Peng: I think future bzr-search loggerhead foo will be microbranches off trunk
[11:17] <Peng> lifeless: Okay. :)
[11:18] <lifeless> abentley: so, what do you need info wise for the squid instance of bb
[11:22] <awilkins> igc: If you trust me, you can have a 1.6b3 installer (with/without fast walk)
[11:25] <igc> awilkins: I trust you. The main issue is coordinating with markh. I know he's been making changes to the installer so that TortoiseBzr is an optional install. It would be nice to have that IMO.
[11:25]  * markh 's ears prick up :)
[11:25] <igc> I also know those installer changes didn't make it into bzr.dev
[11:25] <igc> markh: hello!!
[11:26] <igc> markh: poolie has released 1.6b3 tonight
[11:26] <markh> I'm yet to catch up on your discussion, but it seems likely I will build the 1.6 binary for windows
[11:26] <markh> damn poolie - hasn't he anything better to do ;)
[11:27] <markh> awilkins: I agree msvc should be used
[11:27] <igc> awilkins was offering to do the windows installer. He and I are interested in including jam's fast walkdirs patch in the windows installer but it still needs a bit more review by someone familiar with pyrex
[11:28] <markh> I believe many of the developers would like to ensure the binaries can be built with cygwin though, even if just for their own personal use
[11:28] <awilkins> markh: I have a 7.1 build environment (using the MS 2003 C++ toolkit, which had the optimizing compiler - they've since pulled it of the web)
[11:28] <markh> I believe poolie is keen to get the current state of tbzr out too
[11:28] <markh> I'm using the full retail version of that compiler
[11:28] <poolie> hello markh
[11:28] <poolie> yes i am :)
[11:28] <lifeless> markh: I don't care about cygwin per se; I do care that a completely free toolchain works
[11:28] <igc> markh: *lots* of us are keen for that!
[11:28] <awilkins> markh: It's more the case that some things that gcc 4 series allows, MSVC (even 9.0) can't cope with
[11:28] <markh> hi poolie :)
[11:29] <poolie> lifeless: bb was performing ok for me a while ago
[11:29] <poolie> hm but apparently not now
[11:29] <awilkins> markh: And also some of dependencies are built with msvc 7.1 ; in the case of bzr-svn you just can't link to them if you build using mingw
[11:29] <lifeless> I clicked on merge requests, 15 seconds to dispaly :{
[11:29] <awilkins> markh: Also, mingw is still on gcc 3.4 which can't cope with some of the C99 isms anyway
[11:30] <markh> awilkins: so these things msvc doesn't support - do we really care?
[11:30] <awilkins> markh: But I agree, completely free toolkit compatibility is not an optional feature
[11:30] <jelmer> abentley, ping
[11:30] <awilkins> markh: Had to patch a load of that stuff out of the new svn bindings in bzr-svn
[11:30] <markh> I think it prudent to build everything using the official compiler for the python version we allow
[11:31] <markh> s/allow/release with/
[11:31] <awilkins> markh: In that case it was just sugar - convenient struct initializers
[11:32] <markh> I've been meaning to look at the svn plugin for the binary release - still finishing qbzr at the moment.  So the problem is that msvc is struggling with the svn plugin?
[11:33] <awilkins> markh: Not anymore.. but jelmer would have to tell you how well it works, I've been sending him test logs but not really using it
[11:33] <markh> so what are we discussing? ;)
[11:33] <awilkins> Which compiler to build releases with ?  :-)
[11:33] <markh> I'm happy for someone else to build binaries, but that will require a little pain to bet tbzr working
[11:33] <jelmer> awilkins, Any chance you can rerun that btw?
[11:34] <jelmer> awilkins, There should be a fair number of errors fixed now
[11:34] <awilkins> jelmer: Sure, I was just gearing up for it :-)
[11:34] <markh> but that was due to it appearing I would be building things de-facto
[11:34] <markh> um - my assuming I would build the binaries was due to that...
[11:38] <awilkins> I've not got bzr.exe building yet because I don't use it
[11:38] <awilkins> What are the deps for tbzr?
[11:38] <markh> awilkins: so you have the svn plugin building as part of the binary build process, or you have a binary version of the svn plugin installed that you pick up?
[11:38] <awilkins> markh: I build the bzr-svn pyd extensions myself
[11:38] <markh> not much in the way of external deps - pywin32 is about all - but a number of patches to the build process that aren't yet in bzr.dev
[11:39] <markh> and py2exe just finds and packages the plugin for you?
[11:39] <awilkins> markh: Ahahahahaa
[11:39] <awilkins> markh: Hang on... no, I'm not using py2exe
[11:39] <awilkins> markh: I'm building python_installers
[11:40] <markh> but you are talking about making binaries?
[11:40] <markh> right...
[11:40] <markh> ok, I'm with you!
[11:40] <markh> I'm talking about stand-alone binaries
[11:40] <igc> night all. have fun packaging 1.6b3 . It's looking like 1.6 is going to be a pretty impressive release!
[11:40] <markh> you are talking about distutils installers?
[11:40] <markh> 'night ian!
[11:41] <markh> awilkins: bdist_wininst?
[11:41] <awilkins> markh: I'm talking about 1) binary extensions (pyd) for bzr-svn 2) The win32 installers are (I presume) distutils ones - the ones that are a small exe / zip archive
[11:41] <markh> right - how do you build that exe?
[11:41] <jelmer> ToyKeeper, ping
[11:42] <awilkins> markh: "make python-installer"
[11:42] <markh> ahh - I didn't know about that target ;)  lemme look...
[11:42] <awilkins> markh: The tricksy bits were configuring distutils to use the correct compiler environment for the pyd extensions
[11:43] <markh> yeah - bdist_wininst!
[11:43] <markh> so cool, we are talking about different things and not overlapping at all.
[11:43] <awilkins> Groovy
[11:43] <markh> but we appear to have a terminology issue ;)
[11:43] <awilkins> I'm not building the the installer that installs bzr.exe because I don't use it (wanting to use bzr-gtk n'all)
[11:44] <markh> yup - that is what I'm talking about - but will be bundling qbar instead of bzr-gtk it would seem :)
[11:44] <markh> qbzr
[11:44] <awilkins> Does that use qt4?
[11:45] <markh> yep
[11:45] <awilkins> Ah.
[11:45] <markh> looks slick too
[11:45] <awilkins> I think tbzr should be working to rip off as much as possible as of the TSVN UI
[11:45] <awilkins> Because it's very mature and frankly, very good
[11:45] <markh> not quite as advanced as bzr-gtk yet, but tons of potential ;)
[11:46] <markh> yes, I agree tsvn has real world experience we can't even start to try and re-invent
[11:46] <awilkins> A generic "TortoiseVCS" shell would be great for bzr, git, monotone, anything ; you need some new idioms for _D_VCS but other than that, it's great
[11:48] <markh> yeah - that would be perfect - but I need to ensure we don't get distracted from ensuring the no 1 priority is tbzr.  But I'd love for the other vcs people to leech off the work I'm doing ;)
[11:48] <markh> I plan on leaching off the qbzr project as much as possible - the more we steal, the more we all win ;)
[11:48] <markh> that's why I love this industry ;)
[11:50] <markh> (with their approval and support of course ;)
[11:50] <awilkins> Agreed, it's nice working for a .gov.uk as well ; I have no worries about stupid commercial lawyer crap
[11:51] <ToyKeeper> jelmer: ?
[11:51] <awilkins> My current project has been fertile ground for OSS projects ; I've submitted patches to three or four on the back of it.
[11:51] <jelmer> ToyKeeper, Never mind, just sent review feedback to your bzr viz diff panel patch
[11:53] <markh> awilkins: nice :)
[11:53] <fullermd> jelmer: By the way, when/why did viz stop letting me resize the columns?
[11:53] <ToyKeeper> fullermd: IIRC, around r500 or r490
[11:54] <ToyKeeper> That's one other thing I was thinking of fixing.
[11:54] <jelmer> fullermd: Not sure, I don't think that was an intentional change
[11:54] <fullermd> Mmm.  496.2.1, looks like.
[11:55] <ToyKeeper> jelmer: BTW, I discovered the bitlbee-otr branch today.  Any idea if that's something which might get merged into trunk?
[11:56] <jelmer> ToyKeeper: I don't think that's likely to be merged into trunk
[11:56] <jelmer> ToyKeeper, it was pretty intrusive iirc
[11:57] <ToyKeeper> It seems like an easier and more complete encryption solution than doing each protocol individually, but I don't know the details.
[11:58] <ToyKeeper> The US is a scary place to talk unencrypted lately.
[11:58] <markh> awilkins: do you happen to use bzr with password protected ssh keys?
[11:58] <jelmer> ToyKeeper: That sort of thing should rather be done as a plugin, but I'll defer for wilmer for the decision on that
[11:59] <ToyKeeper> jelmer: Okay, just curious.  I only discovered it today, and it was definitely not a trivial merge.
[11:59] <awilkins> markh: Yes, I do
[11:59] <awilkins> markh: I use pageant to hold onto them
[11:59] <markh> awilkins: do you need to set BZR_SSH?
[11:59] <markh> and do you have ssh.exe on your path?
[12:00] <markh> (I understand you don't use ssh.exe - but it may still exist)
[12:00] <awilkins> markh: If you install paramiko 1.7.3 it works without ; setting BZR_SSH to "plink" also works if you have plink on your path
[12:00] <markh> yes - I'm particularly interested if you *do* have a copy of ssh.exe on your path as well though
[12:00] <awilkins> markh: "ssh" appears to be an alias of plink on this machine (never tried that before)
[12:00] <markh> right - damn :(
[12:01] <awilkins> Aha.
[12:01] <markh> no problem - it just means I need to do more testing ;)
[12:01] <awilkins> I think it's because darcs for win32 rips plink off and renames it ssh.exe
[12:01] <jelmer> ToyKeeper, reading the attached bugreport, it seems the general opinion is that otr should be in your irc client rather than bitlbee
[12:01] <jelmer> since bitlbee may be on a remote host, etc
[12:01] <markh> I *think* that if you have a regular (eg, cygwin) ssh.exe on your path, things may not work as desired, even with paramiko, without setting BZR_SSH
[12:02] <markh> as I *think* ssh will end up preferred, and therefore not use pageant
[12:02] <ToyKeeper> jelmer: For public servers, yes.  But for private ones it's not a problem.
[12:02] <awilkins> markh: AFAIK cygwin do not recommend plopping the cywin bin on the path
[12:02] <markh> (paramika does pageant even without plink)
[12:02] <awilkins> markh: I use gnuwin32 for my *ix satisfaction (but I also have cygwin installed)
[12:02] <jelmer> ToyKeeper: Still, it seems sensible to have that support in the IRC client rather than in the proxy
[12:02] <markh> I have it set at my terminal sessions, not globally
[12:03] <ToyKeeper> Having OTR in the client would make logging on the server pretty much impossible, if I understand correctly.
[12:03] <markh> my global path I keep clean, and just have a "dev" environment in the dos boxes
[12:03] <markh> (well, thats not strictly true, but the intent ;)
[12:03] <awilkins> markh: You're tidier than me then :-)
[12:04] <markh> I always answer "no" when someone offers to set my global environment - even the MS dev tools ;)
[12:04] <awilkins> They come with a perfectly good ENV batch file
[12:04] <ToyKeeper> Every bitlbee user I've talked to runs their own instance, and generally connects to it via openvpn or ssh.
[12:04] <markh> exactly :)
[12:05] <awilkins> markh: Besides, once you've gone through the pain of setting it up once, you forget less easily
[12:05] <ToyKeeper> Anyway, off topic.  :)
[12:12] <jelmer> ToyKeeper, Yes, but BitlBee doesn't log anyway
[12:12] <abentley> jelmer: pong
[12:13] <jelmer> abentley, I've updated my BundleBuggy but now it's broken :-)
[12:13] <jelmer> abentley, Missing table "project"
[12:13] <ToyKeeper> Ah, but dirproxy/bip/etc do, and they'd be logging encrypted junk.
[12:13] <abentley> jelmer, downgrade.
[12:13] <abentley> I haven't written an SQLite migration yet.
[12:14] <jelmer> abentley: hmmok
[12:14] <jelmer> abentley, I was actually thinking - if it was possible to do that migration, I could take my instance offline altogether
[12:14] <jelmer> abentley: (migration of voters)
[12:14] <abentley> jelmer: I already gave you the ability to create voters.
[12:15] <jelmer> abentley: I wasn't aware of that, sorry
[12:15] <uws> The .bzr/repository/obsolete-packs directory uses a lot of space in my repo
[12:16] <uws> what use is it?
[12:16] <abentley> jelmer: seejhttp://bundlebuggy.aaronbentley.com/project/bzr-gtk
[12:17] <abentley> That should have a "add voter" link
[12:18] <abentley> jelmer: You previously said that the ability for you to add voters was a prerequisite for switching.
[12:18] <jelmer> abentley: Ah, thanks
[12:18] <jelmer> abentley, Yep
[12:18] <jelmer> abentley, I wasn't aware it'd been added in the mean time
[12:19] <jelmer> Now I just need to figure out if there's no merge requests that're missing from your bundlebuggy
[12:19] <abentley> Yeah, I was going to announce it, but I've been busy and sick.
[12:19] <abentley> lifeless: I'm not sure what kind of info you mean.
[12:19] <jelmer> abentley, Anyway, thanks for that. I'll keep mine down then.
[12:23] <ToyKeeper> I wonder why hasattr swallows exceptions.
[12:24] <markh> I'm not yet familiar with the release processes - but I don't understand why I can't see a lp:bzr/1.6?  Where does 1.6b3 live?
[12:25] <awilkins> 1.6b3 is a revision of trunk
[12:25] <awilkins> Is it tagged?
[12:25]  * awilkins goes and looks
[12:25] <awilkins> Hah, no tags at all
[12:26] <markh> ToyKeeper: it kinda means "would getattr() work?"
[12:26] <fullermd> It's usually around -rc1 that a branch gets created for a release.
[12:26] <markh> not that I'm justifying the behaviour ;)  I think later version of Python only hide BaseExceptions, or something like that...
[12:26] <awilkins> How do you chaps know which revision you tarballed up as b2 b3 etc ?
[12:27]  * fullermd thinks "we don't" is the answer.
[12:28] <ToyKeeper> markh: I always figured it reduced to something like "return (name in obj.__dict__)", but apparently not.
[12:29] <markh> problem is the types have a C implemented "slot" for getattr - so it is closer to "return ob->tp_getattr(ob, name)==0;"
[12:30] <markh> obviously that is an incredible over-simplification ;)
[12:30] <Odd_Bloke> abentley: http://bundlebuggy.aaronbentley.com/project/pqm/request/%3C20080717114939.35d304df@lapbert%3E should have Superseded http://bundlebuggy.aaronbentley.com/project/pqm/request/%3C20080717112642.32820ec6@lapbert%3E (I believe).  The problem seems to have been caused by sending the second one before BB had received the first.
[12:30] <markh> in so many ways
[12:31] <markh> __dict__ is just what a number of those type slots use as implementation
[12:34] <LarstiQ> markh: hmm, betas are new to me, I only ever did rcs
[12:34] <LarstiQ> (release process wise)
[12:37] <markh> hi LarstiQ!  How was the fesitval?
[12:37] <lifeless> abentley: I hope you are feeling better
[12:37] <lifeless> abentley: I mean, 'is it ready to roll if people send bundles'
[12:38] <lifeless> uws: it helps in the presence of unreliable file systems
[12:38] <abentley> lifeless: It's ready to accept bundles, but for now, only registered voters can vote.
[12:38] <lifeless> uws: and it will be auto-cleaned as you make commits etc
[12:38] <abentley> lifeless: I've set you up as the project admin, so you can add voters if you like.
[12:38] <lifeless> abentley: cool thanks
[12:39] <abentley> I've done the DB patch to enable random people to vote, but I haven't written the code yet.
[12:39] <markh> so from a process POV, awilkins and I should just continue to use bzr.dev to build binaries?
[12:42]  * markh prepares to show more ignorance...
[12:44] <markh> so - does lp:bzr/1.5 have a formal relationship to bzr.dev?  "bzr info" doesn't seem to show one
[12:44] <markh> and why can't I see tags for any older versions in bzr.dev?
[12:45] <Peng> markh: For whatever reason, there aren't any tags.
[12:45] <Peng> markh: And, release branches are branched off of bzr.dev, and usually merged back in a bit later.
[12:46] <markh> but the branches don't show a relationship?
[12:46] <markh> or am I not asking the right question? :)
[12:47] <Peng> markh: Release branches are branched off of bzr.dev -- they're totally related.
[12:48] <fullermd> He means in the stored branch locations.
[12:48] <fullermd> There wouldn't be; they get push'd up there, never manipulated directly.
[12:48] <Peng> Oh.
[12:52] <LarstiQ> markh: great! Although I slep through parts of it, the location is rather incredible and I saw some really good acts.
[12:52] <markh> Peng: so how do I get bzr to tell me about that relationship?
[12:53] <markh> LarstiQ: anyone I would have heard of?  I quite like electronic music
[12:57] <uws> lifeless: Ah, so the wasted space will be freed when I start working on this code?
[12:58] <lifeless> uws: yes
[12:58] <uws> Ok, thanks.
[12:59] <uws> How do I change a repository from "create trees by default" to "create no trees by default" ?
[13:00] <lifeless> owplease file a bug on bzr saying reconfigure should allow this
[13:00] <lifeless> also, touch .bzr/repository/no-working-trees
[13:00] <LarstiQ> markh: http://konemetsa.net/?c=2 is the full list
[13:01] <awilkins> offtopic : MOo!  https://bugs.launchpad.net/launchpad/+bug/56125
[13:01] <LarstiQ> markh: I'll recommend a couple of those later when I have more cycles
[13:02] <abentley> jelmer: If you try with Vincent again, it shouldn't prompt you for a username or password.
[13:04] <jelmer> abentley: I was using a different email addres from him, that's why it was prompting me for a username+password
[13:05] <awilkins> markh: I've not been using bzr.dev, I've been using release tarballs
[13:05] <jelmer> abentley, or are you saying it should be fied now?
[13:05] <abentley> jelmer: I know.  I've associated that email with his user now.
[13:05] <jelmer> s/fied/fixed/
[13:05] <jelmer> abentley, ah, ok
[13:06] <markh> bbiab
[13:09] <ToyKeeper> jelmer: Okay, the diff can be put at the bottom now.  Let me know if you like it.
[13:15] <markh> LarstiQ: bugger, only DCOM rings a bell, but I'm pretty sure that isn't a band I'm thinking of :)
[13:15] <markh> a couple of pointers would be nice though!
[13:17] <markh> awilkins: that should work for me once the build changes to bzr.dev land and stabilize
[13:21]  * awilkins has his first cup of tea of the day, finally
[13:34] <lifeless> jam: good morning
[13:53] <jam> hi lifeless, good afternoon to you
[13:53] <jam> I'm trying to investigate further, but it would appear that 'bzr status' time has regressed in bzr.dev
[13:54] <jam> then again, maybe its just because I'm off wall power right now
[13:57] <awilkins> jam: Yeah, those crazy processorons need high voltage to accelerate them properly.
[13:58] <awilkins> jam: I've seen misconfigured SpeedStep slow machines down even though they were plugged in.
[13:59] <jam> Well, changing my laptop from "Performance Optimized" to "Max Power" changes the "bzr status" time
[13:59] <jam> from 12s
[13:59] <jam> down to 4s
[14:00] <jam> And with my changes from 2s => 0.8s
[14:00] <awilkins> Did you repeat with Perf op again?
[14:00] <jam> So about 2-3x in 'bzr status' time
[14:00] <jam> awilkins: yeah, it is reproducible
[14:00] <jam> I just switched back to not kill the battery
[14:00] <awilkins> Nasty
[14:00] <jam> I don't know whether it is CPU or disk, but yeah, big difference there
[14:01] <awilkins> Disk should be the same
[14:01] <awilkins> I'm not aware of anything that changes spin speed and seek times on different power settings
[14:01] <awilkins> The difference surprises me
[14:02] <lifeless> I've seen it too
[14:02] <awilkins> It's larger than I would expect, I would expect a linear scaling and I've never seen power management drop CPU speed to less than half, let alone less than 1/4
[14:02] <lifeless> on linux at least its latency involved in some manner
[14:02] <jam> real    0m1.226s
[14:02] <jam> user    0m0.000s
[14:02] <jam> sys     0m0.045s
[14:02] <jam> Not a lot of cpu there
[14:03] <jam> There is a "Power Usage" field
[14:03] <jam> "Performance, System Temp, Fan Sound, Power Usage" are the individual tweak
[14:03] <awilkins> Actually, do your changes reduce the number of Disk IOs?
[14:04] <jam> awilkins: Well, my changes switch from calling FindFirstFile() on *every* file in the filesystem, to just iterating over each directory.
[14:04] <jam> It wouldn't *have* to hit disk for it
[14:04] <jam> but I don't know whether it does or not
[14:04] <jam> Anyway, lifeless, no regression :)
[14:04] <awilkins> I suspect that once it's read the MFT once it wont bother
[14:07] <awilkins> jam: Your walk_files won't work on win98, but who cares....
[14:08] <awilkins> jam: You have a comment # Some reserved stuff here   - don't you need to declare those fields, or does Pyrex take care of that?
[14:14] <Odd_Bloke> thumper: Do you have any more work building on your queue-abstraction-2 branch?
[14:19] <jelmer> awilkins, thanks for the updated log
[14:19] <jelmer> I've fixed the issue with the separator being wrong in ignores
[14:19] <awilkins> jelmer: You're welcome
[14:20]  * awilkins pulls
[14:20] <jelmer> One sec, haven't pushed yet :-)
[14:20] <jelmer> I'm not quite sure what's going on with the "file already versioned" errors
[14:21] <Peng> BTW, you guys all rock, and are doing an amazing job on Bazaar, bzr-svn, Launchpad, Loggerhead, and everything else.
[14:21]  * Peng goes to bed.
[14:21] <lifeless> night Peng
[14:21] <awilkins> jelmer: Hmm, maybe I'll have a look at that then, being closer to the platens as it were
[14:22] <awilkins> jelmer: I know all these "can't delete the temp folder" errors are annoying
[14:25] <jelmer> abentley, Any chance you can add "lp:bzr-gtk" to the list of valid branch urls for bzr-gtk?
[14:25] <philn> hi
[14:25] <jelmer> hi philn
[14:25] <philn> i upgraded bzr to 1.6 beta 3 this morning and bzr visualize doesn't work anymore
[14:25] <jelmer> awilkins: Any clue as to why those "file already versioned" errors are occurring would help a lot I think
[14:25] <jelmer> philn: What error do you get?
[14:25] <jelmer> philn, and what version of bzr-gtk are you using?
[14:26] <abentley> jelmer: okay, but I think it's better to use the real URL.
[14:26] <jelmer> it's quite nice to be able to use "bzr send lp:bzr-gtk"
[14:26] <philn> http://pastebin.com/m5e375dc4 bzr-gtk 0.93.0-1
[14:26] <jelmer> philn, you'll need the trunk of bzr-gtk probably
[14:26] <pickscrape> We're imminently going to be migrating from svk to bzr, and a colleague just asked me a question that I can't properly answer myself
[14:27] <lifeless> pickscrape: shoot
[14:27] <pickscrape> When checking out a working tree, he's under the impression that it will build up all files using the diffs from the bugingging of time, which to me sounds a little off :)
[14:27] <jelmer> abentley, Any particular reason lp:bzr-gtk should be considered bad?
[14:27] <pickscrape> beginning
[14:27] <abentley> jelmer: It's not a real url.
[14:27] <lifeless> pickscrape: no, we dontdo that :)
[14:27] <jelmer> philn, yeah, you need to run bzr-gtk trunk
[14:27] <philn> jelmer: lp:... ?
[14:27] <lifeless> pickscrape: it would scale hrribly :)
[14:27] <jelmer> philn, yeah, lp:bzr-gtk
[14:28] <jelmer> abentley, bzr send could expand it (-:
[14:28] <pickscrape> lifeless: yeah, I didn't think so. How does it work then? I know that svn store shole versions occasionally, but I'd imagine this is even more clever
[14:28] <philn> then, can it run uninstalled?
[14:28] <pickscrape> whole
[14:28] <jelmer> philn, yes
[14:28] <jelmer> though I guess directory services need public/private url support for thats first
[14:28] <lifeless> pickscrape: we have a delta compression layer
[14:29] <lifeless> pickscrape: in packs and knits this is just forward deltas, with a snapshot every time the delta chain sums to the size of the full text
[14:29] <lifeless> pickscrape: so its capped at reading a total of the size of each file uncompressed
[14:29] <abentley> jelmer: Yes.  That would probably be best.
[14:30] <abentley> jelmer: Well, if bzr send expanded it for you, it would expand to bzr+ssh...
[14:30] <pickscrape> Gah, compiz just threw my #bzr window off the screen in a wobbly fit :(
[14:30] <abentley> And that's not a publically-accessible url.
[14:31] <pickscrape> I'll wait for the logs to catch up to see what I missed.
[14:32] <jelmer> abentley, Yeah - directory services would need public/private url support for thats first
[14:32] <philn> jelmer: cool, works
[14:32] <philn> thx, new bzr-gtk looks nice
[14:32] <mars> hi all.  I just upgraded to bzr1.6b3, and I noticed that is goofed up my $PS1 prompt.
[14:33] <lifeless> mars: hi, wop
[14:33] <lifeless> woops
[14:33] <mars> it activated /etc/bash_completion/bzrbashprompt.sh, and now $PS1=\u@\h:$(__prompt_bzr)\W\$
[14:34] <philn> kthxbye
[14:35] <lifeless> elisa - http://elisa.fluendo.com/download/
[14:35] <lifeless> lp:elisa <- :)
[14:36] <mars> lifeless, the neat trick is that it overriding what I have in .bashrc.  A new terminal gets the messed up prompt.
[14:36] <lifeless> mars: yeah, I've marked our bug critical
[14:36] <lifeless> now we need someone that knows bash prompt foo to fix it
[14:36] <lifeless> *your*
[14:37] <mars> lifeless, cool, thanks
[14:44] <lifeless> mars: did you install the deb ?
[14:44] <lifeless> mars: or get the tarball ?
[14:44] <mars> lifeless, deb
[15:03] <Odd_Bloke> abentley: BB doesn't seem to be processing requests.  The final email in http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/43992 doesn't seem to have been picked up.
[15:06] <abentley> Odd_Bloke: A look at the mail queue suggests it's waiting to be processed: http://bundlebuggy.aaronbentley.com/mail/queued/msg.G5fC
[15:08] <Odd_Bloke> abentley: Ah, didn't realise that you could look at the queue.  Thanks. :)
[15:08] <pickscrape> What is the correct way to remove a working tree from a branch?
[15:09] <jam> awilkins: So.. the Pyrex cdef stuff is just to let pyrex know that there are some members that you can address, and what type they are so it can do the conversion. It doesn't actually declare a struct in the C code, it assumes that it is declared in the included header.
[15:09] <jam> awilkins: so no, you don't need to declare the reserved fields
[15:09] <jam> And yeah, I thought about win98, and was going to point that out to bialix
[15:09] <jam> Do you know if FindFirstFileA exists on Win98?
[15:10] <Odd_Bloke> pickscrape: bzr remove-tree
[15:11] <lifeless> jam: I believe it is\
[15:12] <pickscrape> Odd_Bloke: excellent, thanks
[15:12] <jam> lifeless: though probably as a plain "FindFirstFiles" I would guess... and not something *I'm* willing to code
[15:12] <jam> but if someone wants to do it, I can point them in that direction
[15:12] <jam> My big thought was to just make the code fall back to non-optimized if it isn't available.
[15:13] <lifeless> jam: yes
[15:14] <jam> mwhudson: Are you around? I just got an email saying I won a UK lottery, and I was wondering if you could pick it up for me
[15:14] <jam> Odd_Bloke: Maybe you could?
[15:14] <jam> :)
[15:14] <jelmer> I thought mwhudson was in .nz these days?
[15:14] <Odd_Bloke> jam: Sure, but I'll need £200,000 of processing fees.
[15:15] <Odd_Bloke> Which you'll need to deliver to my associates in Nigeria.
[15:16] <lifeless> jam: mwhudson is in NZ :)
[15:16] <awilkins> jam: The docs I'm looking at now don't have a specific FindFirstFileW, but they do use TCHAR for strings (which equates to WCHAR on unicode platforms)
[15:16] <jam> lifeless: yeah, I forgot he moved again :(
[15:17] <jam> awilkins: If you look closer on the MSDN site, they start off by just talking about FindFirstFile and then later on say it will be FindFirstFileW for unicode
[15:17]  * awilkins is in the UK, but I'd need a 2% processing fee to pick up your lottery win
[15:17] <jam> awilkins: 2% is a lot better than the  £200,000 Odd_Bloke wants :)
[15:17] <Odd_Bloke> awilkins: Whereabouts in the UK are you?
[15:18] <jam> heh, I guess it is the same
[15:18] <jam> apparently I won 1M
[15:18] <awilkins> Western suburbs of manchester
[15:18] <jam> Contact Mr. Pinkett for the claim of £1,000,000 pounds which youhave won in UK NATIONAL LOTTERY. Provide your Names, Address,Age,Occupation,Tel,Country Send: claimsoffice1@btinternet.com
[15:18] <jam> Like... who would actually *believe* that? There isn't even any colored HTML to make be believe they come from a real scammer
[15:18] <jam> *cough* lottery
[15:19] <awilkins> Anyone who believes that a lottery hands out prizes to people without tickets is a bit dim, to be honest
[15:20] <awilkins> But then again, they are only a little worse than the lottery itself
[15:21] <awilkins> Both exploiting the same disease, just with different degrees of virulence
[15:22] <jam> awilkins:  And state approval
[15:22] <jam> At least in the US, most lotteries have to be state sanctioned
[15:23] <awilkins> So do tobacco sales
[15:24] <awilkins> The UK National Lottery does of course, give large amounts of it's profits to charity.
[15:24] <awilkins> But it's telling that one of our better-liked tycoons offered to run the whole thing on a non-profit basis and was turned down.
[15:27] <jam> awilkins: Well, I was always told that the lottery is just an extra tax on people that are bad at math
[15:27] <jam> As I understand it, most state lotteries do make a decent amount of extra money
[15:27] <jam> whether that goes to charity, etc.
[15:28] <awilkins> jam: Yeah, I detest gambling ; I'm always amazed that people don't drive into Vegas, take a look around, say "hang on, how do they pay for all this glitz?" and then promptly drive out again
[15:31] <jam> It depends on the level of gambling. I don't do it much, but when I do, I basically go in expecting to spend my $XX and be entertained for a while.
[15:31] <jam> If you look at it as a simple entertainment expense, rather than a "I could win big $$" then it is a lot more manageable
[15:33] <awilkins> jam: I can see the attraction from that sort of perspective ; I do enjoy it when I do it. But that supports the side of it that takes more than disposable income
[15:34] <jam> yeah, the cyclical trap of "if I can just get back to even" ...
[15:34] <awilkins> PLaying poker with buddies is probably fine. Playing with casinos is not, because the casino has no incentive to stop - presumably your buddies will stop taking your money if they suspect you can't afford it
[15:34] <jam> awilkins: depends on your buddies :)
[15:34] <awilkins> Well, a casino doesn't want you destitute either ; but that's so you can come back and lose some more
[15:34] <jam> But yeah, playing in a semi-controlled environment
[15:34] <Odd_Bloke> Also your buddies aren't systematically taking the money of people who can't afford it.
[15:35] <Odd_Bloke> I hope.
[15:35] <awilkins> Loius Theroux did a very good Vegas documentary
[15:35] <awilkins> They have these guys who are just there to make high rollers feel welcome
[15:37] <awilkins> Watching the guy on the phone negotiating to get this guy $3,000 on a casino gift card was astounding.
[15:37] <awilkins> Presumably, that's $3,000 _value_ and not cost
[15:37] <awilkins> And the man was a few tens of thousands down.
[15:38] <jam> My wife visited vegas with a friend from out of the country who had some $$ to spend
[15:38] <jam> And they really treat you well when you are willing to lose :)
[15:38] <jam> Complementary meals, lodging, all kinds of stuff
[15:39] <awilkins> Yeah, this guy was staying in a suite with more floor area than my house
[15:39] <awilkins> And all on the casino
[15:39] <awilkins> The real estate must have been very cheap in the beginning ; just a patch of desert
[15:40] <awilkins> Maintaining it must cost a ton ; water, AC, pretty lights, etc.
[15:40] <awilkins> Someone should work out how environmentally unfriendly Vegas is
[15:41] <lifeless> it is the city of sin
[15:41] <Odd_Bloke> Where's Al Gore when you need him?
[15:43] <awilkins> http://green.thefuntimesguide.com/2007/04/las_vegas_energy_use.php
[15:45] <awilkins> Ouch. So, that's 20 MWh of electric per resident, whereas 'mercans use 10MWh per HOUSE on average.
[15:46] <awilkins> (hotel resident)
[15:46] <awilkins> Or maybe residential residents
[15:46] <uws> Can I remove files in .bzr/repository/obsolete_packs, lifeless?
[15:46] <uws> They seem not to get removed after committing
[15:46] <uws> 974M	.bzr/repository/obsolete_packs/
[15:46] <uws> almost 1G
[15:53] <pickscrape> A colleague is getting this error when trying to checkout: "org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute  dbus-launch to autolaunch D-Bus session". Anyhting obvious I should be looking at?
[15:53] <uws> pickscrape: the bzr-dbus plugin perhaps
[15:54] <uws> pickscrape: try unsetting DBUS_SESSION_BUS_ADDRESS or DISPLAY and see if it persists
[15:55] <james_w> pickscrape: if they are on Debian or Ubuntu then installing dbus-x11 might help.
[15:55] <pickscrape> james_w: thanks, I'll ask him to try that
[16:00] <lifeless> uws: the first autopack will trigger removal
[16:10] <beuno> abentley, http://paste.ubuntu.com/28043/
[16:13] <abentley> beuno: What were you voting on?
[16:13] <awilkins> bzr viz
[16:13] <awilkins> oops
[16:14] <beuno> abentley, http://bundlebuggy.aaronbentley.com/vote/%3C20080717133839.GA30741@vernstok.nl%3E
[16:15] <beuno> http://bundlebuggy.aaronbentley.com/request/%3C20080717133839.GA30741%40vernstok.nl%3E
[16:15] <abentley> beuno: The error message looks accurate to me.  You're not a voter on the Bazaar project, and that merge request is for the Bazaar project.
[16:16] <abentley> If you change the request to be a bzr-gtk merge request, then you can vote on it.
[16:17] <beuno> abentley, that fixed, thanks
[16:20] <uws> lifeless: but can I remove the contents of that directory manually? I need the disk space. now! :)
[16:40] <lifeless> uws: yes, leave the dir behind though
[16:41] <pickscrape> uws: That fixed the problem for him, thanks! I'll document accordingly...
[17:00] <GaryvdM> Hi luks
[17:00] <GaryvdM> I've got qdiff to load 1 diff at a time, and update the ui.
[17:01] <beuno> lifeless, is bzr in LP extremely slow for you too by any chance?
[17:01] <GaryvdM> I'm now trying to move the loading to a thread.
[17:02] <GaryvdM> I copied the ProxyToMainEvent class and to_main method from mb picard.
[17:02] <luks> GaryvdM: please don't, threads will not help in python at all
[17:02] <GaryvdM> But I can't get the event to call.
[17:03] <GaryvdM> My code is at lp:~garyvdm/qbzr/diff-images
[17:03] <luks> it will run only in one thread at a time, and since bzrlib is all python it will use all the cpu anyway
[17:03] <luks> the beauty of python's gil :(
[17:03] <GaryvdM> I'm hoping you can help me out.
[17:04] <luks> I can take a look, but I'd really rather not see threads there
[17:08] <luks> can't see anything obvioust from the diffs, I'll try it later
[17:13] <GaryvdM> The reason I wanted to us a thread is that I can't call QtCore.QCoreApplication.processEvents() in the middle of loading a large file. so the ui locks.
[17:13] <GaryvdM> *use
[17:14] <luks> GaryvdM: but using threads will not help that much
[17:15] <luks> due to the GIL it will keep switching between the GUI thread and the loading thread
[17:15] <luks> which will result in blocking as well
[17:16] <lamalex_2> hey guys, I have two branches that do not have a common ancestor, is there a way to merge them? they contain many of the same files, One is an upstream project we forked
[17:18] <GaryvdM> Maybe we don't need it.
[17:19] <GaryvdM> Ok - no thread...
[17:24] <awilkins> jelmer: Ping?
[17:28] <GaryvdM> luks: I think rather leave it. Scrolling is a bit slow when loading a large diff - but not bad...
[17:28] <GaryvdM> I call QtCore.QCoreApplication.processEvents() after each file...
[17:29] <luks> GaryvdM: I'll try it, but I don't think a thread will help with that
[17:34] <LeoNerd> bzr diff | diffstat   <== any way I can use my .bazaar/bazaar.conf  to automate that?
[17:36] <james_w> I think there is a diffstat plugin
[17:36] <james_w> you could also use a shell alias
[17:37] <james_w> but no, there's no way to do that with bazaar.conf
[17:42] <GaryvdM> luks: I agree now  - threads won't help much - so I have dropped that idea
[17:44] <GaryvdM> I've push a working version that does not use thread to lp:~garyvdm/qbzr/diff-images .
[17:44] <lifeless> beuno: seems fine
[17:44] <GaryvdM> I want to squash some regressions and then look at merging to trunk.
[17:45] <beuno> lifeless, it seemed to be something else locally, thanks  (bzr 1.6rc in PPA screwed my shell)
[17:46] <GaryvdM> Regressions are: no line under file info, and no interline diffs.
[17:46] <luks> yep, on my todo list
[17:47] <luks> the lines seem to be tricky
[17:48] <GaryvdM> How were they done before? in the paint event?
[17:49] <luks> yes
[17:50] <luks> but I wanted to move that to the document, to make copy/paste work on file info
[17:52] <GaryvdM> I think I found a way.
[17:56] <bkor> jelmer: are you sure you mean bug 242787 ? there is no info in that bugreport
[17:58] <beuno> jelmer, BB keeps insisting that your patches are for bazaar and not bzr-gtk
[17:58] <beuno> see: http://bundlebuggy.aaronbentley.com/request/%3C20080717121324.GD1834%40vernstok.nl%3E
[17:59] <pickscrape> The work done on bzr-gtk looks very interesting. When is a release expected, or does that depend on 1.6?
[18:02] <strk> how do I create a branch w/out working tree again ?
[18:03] <strk> bzr help branch doesn't say
[18:03] <lifeless> strk: is controlled by the repository; if you want to do it manually you can by 'bzr init foo; bzr remove-tree foo; bzr pull -d foo SOURCE'
[18:03]  * HarryR wonders if bzr-svn supports 1.6 yet :/
[18:04] <strk> lifeless: what's 'foo' and what's 'SOURCE' ?
[18:04] <lifeless> foo is the branch to create; SOURCE is the branch to make it from
[18:05] <lifeless> strk: but the answer you had in #gnash is already correct :)
[18:05] <abentley> jam: around?
[18:05]  * strk continues on #gnash :)
[18:09]  * HarryR downgrades to bzr 1.5 instead
[18:10] <lifeless> abentley: ping
[18:10] <abentley> lifeless: pong
[18:10] <lifeless> HarryR: yes bzr-svn does, but there is no build of it in the ppa
[18:10] <lifeless> abentley: BB - did it notice my woo 2 test ?
[18:11] <HarryR> ah
[18:11] <abentley> lifeless: Yes: http://bundlebuggy.aaronbentley.com/project/squid/request/<1216300191.2781.110.camel@lifeless-64>
[18:11] <abentley> God, do I hate these "friendly" urls.
[18:12] <abentley> lifeless: A reply was sent by Bundle Buggy, but it's being held for moderation.
[18:12] <lifeless> abentley: Ah, I missed that it was from me so noone else could see it :)
[18:13] <abentley> I tried to set up bundlebuggy@aaronbentley.com as a subscriber, but that apparently didn't take.
[18:13] <abentley> lifeless: I really don't like using email for things like that.
[18:13] <lifeless> <things like that> ?
[18:15] <abentley> manipulating mailing list subscriptions.
[18:16] <abentley> I can has web UI?
[18:16] <abentley> It
[18:17] <abentley> has been 3 days since I confirmed that I wanted that address added.  No response yet.
[18:18] <awilkins> jelmer: Looks like it's trying to add a file - it starts with SVN:r1 but when it gets to SVN:r2 it thinks it's a brand new file (even though it's a modify), and gives it a new file_id
[18:20] <jelmer> awilkins: but earlier on in that function it deletes the file from the inventory
[18:20] <jelmer> so I wonder why that's failing
[18:21] <awilkins> jelmer: Meh? this is in the middle of a sprout
[18:22] <jelmer> awilkins: it's being raised from the close() function in fetch.py, right?
[18:22] <awilkins> jelmer: Looking at the log of the svn repo, the operation it's trying to do is the edit of hosts in r2
[18:22] <lifeless> abentley: meh, suqid dev list mgmt is a bit silly IMO
[18:22] <awilkins> jelmer: Yes, the first such error in the log
[18:22] <awilkins> bzrlib.plugins.svn.tests.test_branch.WorkingSubversionBranch.test_fetch_replace
[18:24] <awilkins> jelmer: The error is occurrring on r2 in trunk, not r6 in the branch
[18:26] <awilkins> jelmer: The extensions are calling add_file instead of open_file and then apply_textdelta (I think)
[18:32] <jelmer> awilkins: that's kinda weird
[18:33] <awilkins> jelmer: I presume it doesn't do this on your OS?
[18:34] <jelmer> awilkins: in the case of that particular case it does
[18:34] <awilkins> You can stack dump the proper trace by inserting "assert file_id != '2@6f95bc5c-e18d-4021-aca8-49ed51dbcb75:trunk:hosts'" at line 314 of fetch.py
[18:35] <awilkins> That revid should never exist, there is never a new file called hosts at r2
[18:39] <awilkins> Not screwed up the order of svn_delta_editor_t or something have I?
[18:43] <awilkins> Hmph, looks fine
[18:44] <HarryR> yay finally, `bzr branch` on a svn tree works after downgrading bzr, subversion & neon
[18:44] <jelmer> awilkins: there is - there is a replace action happening at that point, no?
[18:47] <awilkins> jelmer: No, this is revision 2 of the repository
[18:47] <awilkins> jelmer: It's a modify
[18:47] <awilkins> jelmer: The replace is in revision 6
[18:48] <awilkins> jelmer: I'm looking at the repo log - because of the windows tempfile bug, the repo is still there
[18:51] <jelmer> awilkins: ah, you're right
[18:51] <jelmer> it doing an add there is definitely wrong
[19:00] <thumper> Odd_Bloke: the queue-abstraction-2 branch on LP is as far as I have got right now
[19:01] <jam> abentley: sorry I missed your ping, what's up?
[19:02] <abentley> I think you're moving PlanMergeVersionedFile in the wrong direction.  It was turning into a VersionedFiles implementation, and you seem to be turning it back into a VersionedFile implementation.
[19:03] <jam> abentley: for which part?
[19:03] <jam> the add_rev stuff in the test suite?
[19:03] <abentley> get_parent_map
[19:03] <jam> That is just because it is *far* easier to do
[19:03] <jam> I don't believe I touched get_parent_Map
[19:04] <jam> abentley: I'm curious for more info. The problem *I* ran into is that most of PMVF uses tuple keys
[19:04] <jam> but self.get_lines() uses plain revision ids
[19:05] <abentley> Well, I got a conflict there the first time.
[19:05] <abentley> Maybe I misinterpreted why.
[19:07] <abentley> jam: I agree that get_lines is annoying.  Our merge code should move to using the VersionedFiles API anyhow, though.
[19:07] <jam> abentley: Is it because of Jelmer's VirtualVersioned files code?
[19:07] <jam> PVMF.get_parent_map() certainly looks like it is using keys
[19:08] <jam> The only question is the NULL_REVISION issue
[19:08] <jam> Is this correct:
[19:08] <jam> if parents == ():
[19:08] <jam>     result[key] = (revision.NULL_REVISION,)
[19:08] <jam> Or is it supposed to be:
[19:08] <jam> if parents == ():
[19:08] <jam>     result[key] = revision.NULL_REVISION
[19:08] <awilkins> jelmer: Are the parameters in ra.c:992  right?
[19:08] <jam> Certainly there is confusion earlier:
[19:08] <jam> if revision.NULL_REVISION in keys:
[19:08] <jam>     keys.remove(revision.NULL_REVISION)
[19:08] <jam>     result[revision.NULL_REVISION] = ()
[19:08] <awilkins> jelmer: Stabbing in the dark a bit :-(
[19:09] <abentley> I'm in the middle of overhauling get_parent_map so the answer is always (('null:',),)
[19:09]  * jam no likey our current NULL_REVISION issues
[19:09] <jam> Good
[19:11] <abentley> jam: I'm starting to think that it would be a good idea to record that in the indices.
[19:12] <jam> abentley: well, it would lead to less friction
[19:12] <jam> but it makes me sort of wonder why we add it to the graph anyway
[19:12] <abentley> jam: That would give us a way to distinguish between "no parents" and "I don't know what the parents are".
[19:12] <jam> abentley: I thought we never had a "I don't know what the parents are" case
[19:12] <jam> because we just didn't record the node if we didn't know
[19:12] <abentley> jam: reconcile.
[19:17] <abentley> jam: We've had the NULL_REVISION as a concept for a very long time.  Instead of sometimes having it and sometimes not, I think it makes sense to have it all the time.
[19:18] <jam> abentley: I thought we introduced it because we had difficulties with representing ghosts, but I think we have that sorted out a bit better now, and I'm not sure what it really gives us.
[19:18] <jam> I agree it should be all or nothing though
[19:18] <jam> the current apis cause me grief
[19:19] <abentley> jam: The concept of a null revision was part of the Bazaar design from the very beginning.
[19:21] <abentley> I think it's very useful.  It's a revision that all projects have as a common base.
[19:21] <abentley> It's a revision against which even your first commit can be a delta.
[19:24] <abentley> jam: Spelling it 'null:' was more recent, and that let us use None for other things.
[19:26] <jam> abentley: I suppose. As long as we solve the ancillary issues
[19:26] <jam> Like is the parent of ('file-id', 'rev-id') => ('null:') or is it ('file-id', 'null:')
[19:27] <jam> And the current mismatch
[19:27] <jam> that you can get a parent of XX
[19:27] <jam> but if you try to get the text for XX
[19:27] <jam> it fails
[19:27] <awilkins> jelmer: Performing the same operation (switch from url@1 to url@2) on teh command line works.
[19:27] <awilkins> Phooey
[19:27] <jam> And that accessing the parent_map has to filter to translate between the disk form and the memory form
[19:27] <jam> etc.
[19:27] <jam> Anyway, as it is a somewhat artificial construct
[19:28] <jam> it hasn't been clear how it should be propagated throughout our apis
[19:28] <jam> Also, there is a small benefit to being able to loop until you get no more entries
[19:28] <jam> rather than looping until you hit NULL
[19:28] <awilkins> Special class for the null: instance?
[19:28] <jam> Like Graph and tsort both assume the graphs end with an empty set
[19:29] <jam> which sort-of works with NULL, because *its* parents are empty
[19:34] <awilkins> jelmer: You know you can simplify this code, switch works in all cases (I don't know if there are any performance problems with that)
[19:36] <abentley> jam: The parents of ('file-id', 'rev-id') are (('null:',),)
[19:52] <jam> abentley: so all revisions, inventories, file texts, and branches decend from the same object?
[19:52] <jam> That doesn't sound quite right
[19:53] <abentley> Well, I discussed it in #bzr, and that's what we came up with.
[19:54] <abentley> And really, if the object represents nothing, and these things came from nothing, it doesn't seem far wrong to me.
[20:00] <mtaylor> gaaaaahhhhhhh
[20:00] <mtaylor> bzr-svn: Depends: bzr (< 1.4~) but 1.6~beta3-1~bazaar1 is to be installed
[20:00] <mtaylor> sigh
[20:00] <mtaylor> is there an up-to-date-with-current-bzr bzr-svn apt repo around?
[20:05] <wingo-tp> good evening!
[20:06] <wingo-tp> my bzr repository is corrupted: https://bugs.launchpad.net/bzr/+bug/239499 . i imagine other people that have imported from baz or arch might be in the same situation whenever it is that they upgrade repo formats. anyone want to poke that bug? :)
[20:14] <jam> mtaylor: not yet, unfortunately, jelmer hasn't had time to keep the archives up-to-date so it sort of lagged behind
[20:48] <abentley> poolie: ping
[20:48] <mwhudson> abentley: pretty darn early for poolie
[20:49] <abentley> mwhudson: Yeah, though not for lifeless...
[20:49] <mwhudson> lifeless is a special case
[20:49] <mwhudson> in many ways :)
[20:53] <lifeless> mwhudson: thanks I think
[20:54] <mwhudson> lifeless: in good ways, yes
[20:54] <mwhudson> :)
[20:54] <mwhudson> lifeless: did you manage any groupcompress hacking today?
[20:55] <lifeless> sadly no
[20:55] <lifeless> but see my RFC
[21:08] <awilkins> jelmer: Fixed that bug
[21:09] <jam> http://jam-bazaar.blogspot.com/2008/07/this-week-in-bazaar_17.html has been released
[21:09] <awilkins> But first I have to fetch a pint of milk to keep the wifelet happy.
[21:12] <lifeless> jam: errata : 20GB of data
[21:17] <lifeless> night all
[21:25] <jam> lifeless: that is all?
[21:25] <jam> There was a single pack file at 16GB
[21:37] <poolie> abentley: hi
[21:38] <poolie> hello lifeless and jam too
[21:39] <abentley> poolie: Hi.  I had a question about some code you wrote.  Lemme just find it again.
[21:40] <abentley> poolie: knit.py:2688 is that "if True" deliberate?
[21:50] <LaserJock> if I install bzr from bzr.dev will it conflict with installed bzr packages?
[21:50] <LaserJock> do I need to install bzr.dev to a different directory?
[21:51] <wingo-tp> if you have bzr.dev and want to keep the installed package, don't install bzr.dev
[21:51] <wingo-tp> just run it from the source repo
[21:51] <poolie> lifeless: are you still here
[21:51] <LaserJock> hmm
[21:51] <poolie> i guess not
[21:52] <LaserJock> I was wanting to install some related packages in Ubuntu, but they depend on bzr
[21:53] <LaserJock> so I wondering if there is a common solution for that kind of case
[21:55] <poolie> LaserJock: there is a way to tell dpkg 'pretend i have $foo installed'
[21:55] <poolie> i don't recall it off hand
[21:55] <poolie> alternatively, just install the system bzr and put your bzr into ~/bin or something
[21:58] <LaserJock> I think I need to maybe re-evaluate why I'm using bzr.dev in the first place :-)
[21:58] <LaserJock> I think perhaps I've gone down a rabbit trail I don't need to
[22:00] <GaryvdM> luks: I've fixed all qdiff regressions that I am aware of. Any objections to merging to trunk?
[22:03] <LaserJock> poolie: why is bzr 1.6 beta in the bzr PPA?
[22:03] <LaserJock> poolie: shouldn't it be in the bzr-beta PPA?
[22:03] <poolie> LaserJock: ah, because i mistyped :)
[22:04] <poolie> or really, because i mindlessly copied from the checklist
[22:04] <poolie> abentley, jam: i'm wondering if before 1.6 we should either
[22:04] <poolie> a- rename development1 to a supported format or
[22:04] <LaserJock> poolie: so is it really 1.5?
[22:05] <poolie> b- make --stacked automatically give you this format
[22:05] <poolie> i feel a bit strange about doing b and not a
[22:05] <poolie> LaserJock: i don't understand
[22:06] <LaserJock> poolie: the version in the bzr PPA says: 1.6~beta3-1~bazaar1
[22:06] <LaserJock> is that really what it is or is it 1.5 mislabeled
[22:07] <abentley> poolie: I think we should do "a".
[22:07] <abentley> I'm not aware of any format considerations that would prevent it.
[22:08] <abentley> I don't think we should make people use a "development" format to get advertised features.
[22:12] <LaserJock> so .... what's going to happen with the bzr PPA?
[22:13] <pickscrape> Did I read somewhere a while back about per-file commit comments being added?
[22:15] <radix> WOO HOO
[22:39] <poolie> abentley: and then b?
[22:39] <poolie> radix: hi?
[22:40] <poolie> pickscrape: yes, but in a plugin iirc
[22:40] <radix> poolie: I am celebrating the release of a version of bzr with stacked branches :)
[22:40] <radix> should I switch back to the non-beta PPA?
[22:40] <mwhudson> radix: it's only 1.6b3, no release yet
[22:40] <radix> well yes
[22:41] <radix> whatever it's called, there's something I can apt-get
[22:41] <mwhudson> indeed
[22:41] <pickscrape> poolie: thanks, I was trying to figure out why I couldn't find it myself :)
[22:44] <poolie> no, i should put it in the right ppa
[22:46] <abentley> poolie: Doing 'b' is fine with me, but 'a' is the one I really care about.
[22:54] <poolie> ok
[22:54] <poolie> then i guess we should do both
[22:54] <poolie> i was hoping to talk about it with robert
[22:54] <poolie> i think he said it's ok with him to make it a released format
[23:05] <jam> poolie: so... the only effect of the format right now is to enable stacking?
[23:05] <pickscrape> Does anyone know of an example command (core or plugin) that takes a subcommand?
[23:05] <jam> As in, it doesn't introduce rich roots, or btree indexes, or really anything else?
[23:05] <jam> pickscrape: 'bzr shelf ls'
[23:05] <jam> Plugin is bzrtools
[23:06] <jam> poolie: it seems a bit much to require 'bzr upgrade' and only get stacking, when we have so many other things in the queue
[23:06] <jam> Though I agree that it should probably be a fully supported format, just not a recommended upgrade until we get some more bits in.
[23:06] <pickscrape> jam: Ah, yes I'd completely forgotten that shelf does it. Thanks fort he reminder!
[23:18] <libwilliam> I was in here a week or so ago asking about this and someone helped me but I didn't implement it right away and forgot. So I am back for help. I am trying to test and see if a valid bug fixed argument is valid...
[23:19] <libwilliam> Current I am getting a TrackerRegistry instance then calling get_instance("lp", branch) on it and it keeps returning bzrlib.errors.UnknownBugTrackerAbbreviation: Cannot find registered bug tracker called launchpad on BzrBranch6('file:///home/will/bzr/bzrtest/')
[23:20] <libwilliam> whoops, I mean bzrlib.errors.UnknownBugTrackerAbbreviation: Cannot find registered bug tracker called lp on BzrBranch6('file:///home/will/bzr/bzrtest/')
[23:20] <libwilliam> lp instead of launchpad.... the first one was a different test.
[23:20] <libwilliam> So is this the right way to check and I am just not using the proper syntax or am I doing something completely wrong?
[23:22] <poolie> jam, i'll check that but i believe it's just stacking
[23:26] <GaryvdM> libwilliam: i you can remember when it was, the irc logs are here: http://irclogs.ubuntu.com/
[23:28] <jam> libwilliam: I wonder if you need to do "import bzrlib.plugin; bzrlib.plugin.load_plugins()" before you do that
[23:29] <libwilliam> Garyvdm, jam: thanks, I am scrolling through the logs right now to see if I can find it. If not I am going to try the load_plugins()
[23:33] <igc> morning
[23:35] <jam> igc: good morning
[23:50] <colbrac> Is there a method that returns the rev_no of a remote branch? (Like a branch on launchpad)
[23:51] <bob2> bzr revno url
[23:51] <colbrac> no from a brzlib remote branch instance
[23:52] <mwhudson> b.last_revision_info() ?
[23:53] <bob2> revno does Branch.open_containing(location)[0].revno()
[23:56] <colbrac> yay .last_revision_info does the trick. :) Thanks!
[23:59] <spiv> jam: thank you very much for the reviews!