[00:00] <mathrick> mwhudson: yeah
[00:01] <cyberix> still imports the one from site-packages
[00:02] <mwhudson> cyberix: what exactly are you doing?
[00:02] <mwhudson> can you pastebin a session?
[00:03] <cyberix> Just trying to run selftest on a vanilla "checkout" from lp:bzr
[00:04] <mathrick> mwhudson: it seems to be true for bzr+ssh:// as well
[00:04] <Verterok> cyberix: that's weird. try removing/not using your current PYTHONPATH, i.e: PYTHONPATH=/path/to/branch
[00:04] <mwhudson> mathrick: i'm not surprised there
[00:05] <mathrick> why not?
[00:05] <cyberix> http://pastebin.com/d73a21e3
[00:09] <mwhudson> mathrick: because the code for bzr:// and bzr+ssh:// is basically the same at this level
[00:09] <cyberix> Verterok: That doesn't change anything
[00:09] <mwhudson> cyberix: hm, seems to be loading the system plugins
[00:10] <mwhudson> which is wrong, but less wrong than what you first said
[00:12] <cyberix> oh
[00:14] <cyberix> Any further suggestions?
[00:15] <Verterok> cyberix: you can use the --no-plugins option
[00:15] <mwhudson> ./bzr --no-plugins selftest
[00:16] <Verterok> cyberix: also there is the BZR_PLUGIN_PATH env var, in the case that you want to include some plugins in the selftest
[00:24] <mathrick> mwhudson: ok, do you see a fix?
[00:25] <mathrick> I need to know if I should invest into making it work, or rather take care of the reading part of my app
[00:25] <mwhudson> mathrick: not really looked yet
[00:25] <mathrick> aha
[00:25] <mwhudson> mathrick: i wonder if i can trick spiv into fixing it
[00:25] <mathrick> hehe
[00:25] <mwhudson> spiv: https://bugs.edge.launchpad.net/bzr/+bug/175570
[00:26] <mathrick> I think he should feel morally obliged to fix it, he knew the bug number instantly when I mentioned it :)
[00:26] <mwhudson> smart server/remote branches is something he knows more than most about
[00:27]  * mathrick wonders if that is a good thing
[00:28] <cyberix> thanks that helped
[00:29] <spiv> mathrick: "instantly" is a bit of an exaggeration :)
[00:29] <cyberix> going to sleep now
[00:29] <cyberix> good night
[00:30] <spiv> I had to search Launchpad, but happily searching bugs.launchpad.net/bzr for "cat ObjectNotLocked" found exactly 1 bug.
[00:34] <mathrick> excuses
[00:51] <mwhudson> spiv: do you know about the locking thing off hand?
[00:59] <spiv> locking thing?
[01:00] <mathrick> spiv: the bug I ran into
[01:00] <mwhudson> spiv: http://pastebin.ubuntu.com/27148/
[01:03] <spiv> mwhudson: that has the same root cause as 175570, I believe
[01:04] <spiv> There's another related bug report or two, as well.
[01:04] <mwhudson> spiv: well, i was more thinking that it could be the root cause for that bug
[01:05] <spiv> mwhudson: well, that's a symptom, not a cause ;)
[01:05] <mwhudson> spiv: ok
[01:05] <spiv> The cause is roughly that RemoteBranch.lock_read doesn't call lock_read on its repo.
[01:05] <spiv> But just simply doing that breaks other things.
[01:06] <spiv> There's a discussion of this on the list and/or this mysterious other bug report I'm alluding to.
[01:06] <mwhudson> hm
[01:06] <spiv> mwhudson: https://bugs.edge.launchpad.net/bzr/+bug/237067
[01:07] <mwhudson> spiv: yay google
[01:07] <mwhudson> (i just found that too)
[03:49] <CrashTest_> Aha!  I was going to ask a good-ole' stupid question, but I found the answer!  sftp://myuser@domainname.com/~/svr/bzr/ works, sftp://myuser@domainname.com/svr/bzr does not :)  Silly little ~
[05:28] <lifeless> woo, 1.6Million key btrees , no memory _explosion_
[05:29] <lifeless> (and thats not the limit, that was just disk spilling when it blew up cause it exceeded the header size)
[09:25] <lifeless> megarepo test on b+tree indices:
[09:26] <lifeless> 115M    .bzr/repository/indices
[09:26] <lifeless> down from
[09:26] <lifeless> 444M    backup.bzr/repository/indices/
[09:26] <lifeless> poolie: oh yeha, hi :)
[09:55] <poolie> night all
[10:21] <pagenoare> hi
[10:22] <pagenoare> anybody using bzrweb with bzr 1.5rc1? :D
[10:50] <awilkins> lifeless: But are b-trees Faster too?
[11:28] <lifeless> awilkins: igc mailed the list with some results
[11:28] <lifeless> awilkins: executive summary: much faster at some things; a bit slower at others, ~= on the rest.
[12:00] <gabe> hi all
[12:01] <gabe> wondering if someone might be able to help me out with a bzr related problem
[12:01] <gabe> get the following error: bzr: ERROR: [Error 32] ╧ЁюЎхёё эх ьюцхЄ яюыєўшЄ№ фюёЄєя ъ Їрщыє,
[12:01] <gabe>  ╧ЁюЎхёё эх ьюцхЄ яюыєўшЄ№ фюёЄєя ъ Їрщыє, is unreadable meaningless heap of letters!
[12:01] <gabe> reported it on https://bugs.launchpad.net/bzr/+bug/237305
[12:04] <Odd_Bloke> gabe: What OS are you using?
[12:11] <gabe> that's on windows vista with bzr 1.5
[12:13] <Odd_Bloke> Hmm, I don't really know enough about Windows to be able to help you debug. :(
[12:13] <gabe> i know enough about Windows not to use it!
[12:13] <Odd_Bloke> gabe: That said, attaching the relevant part of .bzr.log to the bug report would probably be helpful.
[12:13] <gabe> it's actually a russian friend with the problem
[12:13] <gabe> trying to help him solve it..
[12:14] <gabe> i'll see if i can get hold of bzr log
[12:24] <Splodge> Hi, I'm hoping somebody here can help me: is it possible to compare two branches in bzr?
[12:24] <Splodge> I have a trunk on the server which I've 'branch'ed to my PC. Then, to test things, I updated some files in the working tree and committed them to the local copy of the branch (what's the proper term for this - local mirror?). The question is, is it possible to compare the local copy containing the commits, to the branch on the server in a nice, simple way? Or am I approaching development...
[12:24] <Splodge> ...with bzr incorrectly?
[12:25] <Kinnison> cd local-branch
[12:25] <Kinnison> bzr diff http://path/to/remote/branch
[12:25] <bob2> 'bzr missing' will show the different commits on each, or you can use bzr diff to show diffs
[12:28] <lifeless> gabe: sounds liek the error isn't encoding correctly on output
[12:31] <Splodge>  Ah I see.
[12:31] <Splodge> 'diff' doesn't show anything for me, but 'missing' does list the extra revisions I have locally.
[12:31] <Splodge> And the --verbose item will show extra details on the changes to files etc.
[12:31] <Splodge> That's just what I was looking for. Thank you.
[12:34] <gabe> thanks
[12:35] <gabe> I got a section of the bzr log attached to the bug report, it's here... http://launchpadlibrarian.net/16008570/bzr.log
[13:02] <lifeless> gabe: thanks
[13:17] <awilkins> gabe: ERr 32 is an IO error ; probably a file being held open by another process
[13:18] <awilkins> gabe: Which shell are you using? THe error text looks like it's in unicode or something
[13:36] <awilkins> gabe: Looks like an eastern European error message for err 32. Your local encoding is cp866 so I presume you are cyrillic by nature...
[13:41] <gabe> yeah it's actually a russian friend I am asking on behalf of
[13:41] <gabe> what info do you need?
[13:43] <awilkins> gabe: Well, it's an IO error during a tree transform ; I would suspect that another process has a lock on one of those files
[13:43] <lifeless> hmm, I was going to say bzr --version
[13:43] <lifeless> but it doesn't include the encoding
[13:43] <lifeless> gabe: does your friend see a readable error?
[13:43] <gabe> what he sees is what I pasted here
[13:43] <gabe> error 32 etc
[13:43] <gabe> and some unreadable junk too
[13:44] <lifeless> gabe: if what he sees is correctly encoded cp866 he will be able to read it even though we can't
[13:44] <gabe> he's used bzr for a while
[13:44] <gabe> no problem
[13:44] <lifeless> thats the nature of encoding
[13:44] <gabe> yeah but he said it is junk
[13:44] <gabe> unreadable even to him
[13:44] <lifeless> gabe: so I'm tryingt o understand if *he* can read it, not if the copy and pasted stuff is unreadable
[13:44] <lifeless> ok
[13:44] <lifeless> so there are two issues: why the error, and the error being unprintable
[13:44] <gabe> he has a checkout of a branch
[13:44] <gabe> and been doing about 25 --local commits
[13:44] <lifeless> as for why the error, does he have an editor open on a file or something?
[13:45] <gabe> then wanted to commit back to the repo
[13:45] <gabe> but it said he needed to bzr up
[13:45] <gabe> so he did bzr up and got this
[13:45] <jelmer> hey *
[13:45] <gabe> some conflicts
[13:45] <gabe> and errors
[13:45] <awilkins> He has a file open
[13:45] <lifeless> gabe: I would guess an editor open on a file
[13:45] <gabe> ok
[13:45] <awilkins> It's during a rename
[13:45] <lifeless> jelmer: hi
[13:45] <gabe> i'll make sure he quits any editors and tries again
[13:45] <awilkins> Windows ia waaay more picky about files being open when it writes over them
[13:46] <beuno> mornin' all
[13:46] <jelmer> lifeless: How were things at GUADEC?
[13:46] <lifeless> jelmer: intense :)
[13:46] <lifeless> many positive discussions, some rather more neagative
[13:47] <beuno> lifeless, any guesses on what the outcome for VCS choice will be?
[13:47] <jelmer> lifeless: what in particular were the negative ones about?
[13:49] <lifeless> jelmer: some folk felt that canonical was pushing bzr (rather than us being there because gnome devs *wanted* support for bzr)
[13:49] <lifeless> jelmer: and there were some rather opinionated folk that didn't want a dialogue, but instead wanted to tell me how stupid it was to even hack on bzr given that git exists
[13:50] <jelmer> lifeless: wow, ok
[13:50] <lifeless> beuno: no idea yet
[13:51] <Kinnison> The number of people who think that git is the be-all-and-end-all, perfect, etc. does surprise me
[13:51] <Kinnison> esp. given how I cannot get on with it no matter how hard I try
[13:51] <lifeless> Kinnison: the number of them that have used bzr in anger appears to approach zero
[13:51] <Kinnison> lifeless: surprise surprise.
[13:51]  * Kinnison wishes git was easier and nicer
[13:52]  * Kinnison gave up and did his kernel module dev in bzr and supplied a patch to the kernel guys
[13:52] <Kinnison> because I just can't get git to be of any use to me
[13:52] <jelmer> lifeless: Thanks for the update
[13:53] <lifeless> jelmer: should have a interseting ssvn bug for you soon
[13:53] <jelmer> I'm looking forward to it ;-)
[13:54] <pbor> lifeless: did you persuade any gnomers (that currently use svn/git) to at least try bzr?
[13:54] <lifeless> pbor: yes
[13:54] <pbor> cool
[13:54] <lifeless> rob taylor from codethink appears quite excited :)
[13:54] <asabil> lifeless: are you serious ?
[13:54] <lifeless> Jc2k: how's your head? recovering from guadec?
[13:54] <lifeless> asabil: about what?
[13:54] <asabil> about rob taylor
[13:54] <pbor> getting people to actually try it is the only way to gain user base :-)
[13:55] <lifeless> asabil: yes
[13:55] <asabil> wow !
[13:55] <Jc2k> lifeless: my brain is at about 25% usefulness
[13:55] <asabil> last time I talked to him (a year ago), he was worshiping git
[13:55] <lifeless> asabil: he's had Jc2k hammering on him way before guadec :) I just added the straw I think
[13:55]  * Jc2k nods
[13:55] <asabil> lol :)
[13:55] <Jc2k> not just that though
[13:55] <asabil> well done Jc2k ^^
[13:56] <Jc2k> he's been poking the Git source code for his project
[13:56] <asabil> we need more of you
[13:56] <Jc2k> and Git source would finish anyone of
[13:56] <Jc2k> f
[13:56] <Jc2k> its horrible in there.
[13:56] <pbor> haha
[13:57] <asabil> I think bzr developers maybe should start blogging code snippets from git's source code
[13:57] <asabil> maybe that would shed some light on the evil dark corners of git :p
[13:58] <beuno> jelmer, btw, which BB are we using for bzr-gtk?  it seems we have 2 fighting over it now
[13:58] <jelmer> beuno, vernstok.nl is still the primary one
[13:58] <jelmer> until the one on Aarons machine has the right details
[13:58] <beuno> jelmer, cool, I'm back home now, so I should be able to go through the remaining reviews, and merge some of them
[13:58] <jelmer> cool
[13:59] <beuno> sorry I've been so unresponsive, but I've had a few unusual weeks  :)
[14:00] <fullermd> Heck, I've had a few unusual _months_...
[14:05] <awilkins> vila: Ping?
[14:10] <mtaylor> guys, I love you all, but this: bzr: ERROR: Repository KnitPackRepository() is  not compatible with repository KnitPackRepository()
[14:10] <mtaylor> is quite possibly the worst error message in the history of mankind
[14:10] <lifeless> mtaylor: totally
[14:11] <jelmer> mtaylor: Couldn't agree more
[14:11] <lifeless> mtaylor: and I'm embarrased
[14:11] <mtaylor> ok.
[14:11] <lifeless> jelmer: so patch it up :)
[14:11] <mtaylor> as long as you're embarrassed
[14:11] <lifeless> jelmer: add the rich root etc stuff to str()
[14:11] <mtaylor> also, let me verify...
[14:12] <mtaylor> rich-root-pack is required for former svn repos... but is not recommended at this point for normal use of large projects, say, like the mysql trees?
[14:12] <jelmer> lifeless: Maybe once I finish browsing through the bzr-svn bugs from the last 5 days...
[14:12] <lifeless> jelmer: :)
[14:12] <lifeless> mtaylor: its a one way trap door; shouldn't be performance implications
[14:26] <lifeless> holy cow
[14:27] <lifeless> this index is a 5-level B+Tree
[14:27] <lifeless> 2.9Million keys
[14:29] <awilkins> lifeless: Did you think about incredibly-scary-judy-arrays ?
[14:33] <lifeless> awilkins: yes
[14:34] <awilkins> I never tried them personally, but the papers read really impressively :-)
[14:34] <lifeless> 5 IO's per key -> not ideal. But hey, its all of ubuntu.
[15:05] <lifeless> jelmer: https://bugs.edge.launchpad.net/bzr-svn/+bug/248406
[15:32] <gabe> ok my russian friend closed his editor
[15:32] <gabe> did bzr up
[15:32] <gabe> this is what he said:
[15:32] <gabe> i've closed editor and run bzr up and it completely removed all my changes
[15:32] <gabe> all 26 local commits are disappeared
[15:32] <gabe> why did it do that!?
[15:35] <lifeless> gabe: bzr st will show you a pending merge
[15:35] <lifeless> gabe: and he should now 'bzr commit' to record it and put it in the repository
[15:35] <gabe> oh
[15:36] <gabe> lifeless: thanks for your continued assistance
[15:36] <gabe> i'll check on the bzr st
[15:36] <lifeless> gabe: if he reverted or something then it will have become a dead head and he can do 'bzr heads --dead' or whatever to find the id etc.
[15:36] <gabe> er
[15:36] <gabe> this is what his bzr st shows
[15:36] <lifeless> gabe: check on bzr st :)
[15:36] <gabe> D:\xampp\htdocs\eastwestfilms\hungerseason>bzr st
[15:36] <gabe> unknown:
[15:36] <gabe>   .project
[15:37] <gabe> no merges :(
[15:37] <lifeless> gabe: bzr heads --dead-only
[15:37] <lifeless> gabe: he will need bzrtools installed
[15:37] <gabe> he had a whole bunch of about 25 --local commits
[15:37] <gabe> lifeless: he has been using bzr for a while without problem? Is he really missing bzr tools?
[15:37] <lifeless> gabe: the heads command is in bzrtools
[15:38] <lifeless> gabe: I don't know if he is missing it or not, but to find the id of the commits that he reverted we need bzrtools
[15:38] <Splodge> can anyone tell me how to revert a 'branch'ed that has had some commits made back to the trunk version? a 'revert' only reverts the working tree to the branched copy. do I need to do something with 'pull' or provide some optional parameter. googling has turned up unless i'm just looking in the wrong places... (apologies if it is a stupid question)
[15:38] <gabe> right, i'll make sure he has it installed.
[15:38] <lifeless> gabe: its there in his repository, we just need to pull it back into his tree
[15:38] <lifeless> gabe: try the command, if it's unknown command install bzrtools/upgrade bzrtools
[15:39] <lifeless> Splodge: pull --overwrite
[15:39] <gabe> try this command? zr heads --dead-only?
[15:39] <lifeless> gabe: yes
[15:39] <gabe> bzr heads --dead-only
[15:40] <gabe> what will it do?
[15:40] <Splodge> lifeless: Thanks! You guys are good ;)
[15:40] <lifeless> gabe: report on the name of the stuff he reverted
[15:40] <gabe> ok i asked him to try
[15:40] <gabe> lifeless: you are right, unknown command
[15:40] <gabe> so install bzr tools
[15:41] <lifeless> gabe: yes
[15:41] <lifeless> abentley: ping
[15:41] <abentley> lifeless: pong
[15:42] <lifeless> abentley: nevermind, something stranger than I considered
[15:42] <lifeless> abentley: I have an epic fail on my mega repo; with bzrlib.errors.RevisionNotPresent: Revision {('zopezver.init.in-20080520144343-w8u8nix52axlkvgg-19', 'liw@gytha-20080520144343-7pdk3g344utm17vz')} not present in "<bzrlib.knit.KnitVersionedFiles object at 0x2ac7674f8810>".
[15:42] <lifeless> abentley: but the repo has single commits everywhere so it should be impossible
[15:43] <abentley> lifeless: This is with B+ trees?
[15:43] <lifeless> abentley: yes, though I think that that is orthogonal
[15:45] <lifeless> I know what is happening
[15:45] <lifeless> bug in my bug fix
[15:50] <lifeless> abentley: so yes, it was B+trees
[15:50] <abentley> lifeless: Glad you found it.
[15:52] <gabe> how to install bzrtools
[15:55] <lifeless> abentley: I was handling far right hand end nodes wrong if the node had only one child
[15:56] <Odd_Bloke> abentley: BB doesn't seem to be picking up on when patches have been merged into PQM's trunk (http://bundlebuggy.aaronbentley.com/project/pqm/request/%3C20080710071152.05c913e0@lapbert%3E is the only example ATM).
[15:57] <abentley> Odd_Bloke: Okay, I'll look into it.
[15:58] <Odd_Bloke> abentley: Thanks. :)
[15:58] <abentley> Odd_Bloke: Could you file a bug report, please?
[16:01] <Odd_Bloke> abentley: Sure.
[16:01] <gabe> ok my friend has bzr tools installed
[16:01] <gabe> this is the result of bzr heads --dead-only
[16:01] <gabe> HEAD: revision-id: kos@pixeco.com-20080714080119-60tpfuob57h4zma4 (dead)
[16:01] <gabe>   committer: Kos
[16:01] <gabe>   branch nick: hungerseason
[16:01] <gabe>   timestamp: Mon 2008-07-14 14:01:19 +0600
[16:01] <gabe>   message:
[16:01] <gabe>     Added sIFR for images caption
[16:01] <lifeless> gabe: ok, you can now do 'bzr merge -r revid: kos@pixeco.com-20080714080119-60tpfuob57h4zma4'
[16:02] <gabe> oooh ok
[16:02] <lifeless> gabe: and then 'bzr commit'
[16:02] <gabe> that's very precise :)
[16:02] <lifeless> erm, thats revid:kos...
[16:02] <lifeless> I added a space by mistake
[16:02] <lifeless> like so:
[16:02] <lifeless> 'bzr merge -r revid:kos@pixeco.com-20080714080119-60tpfuob57h4zma4 .'
[16:02] <gabe> ok cheers
[16:02] <lifeless> that will resurrect his patches
[16:03] <gabe> D:\xampp\htdocs\eastwestfilms\hungerseason>bzr merge -r revid:kos@pixeco.com-20080714080119-60tpfuob
[16:03] <gabe> 57h4zma4
[16:03] <gabe> bzr: ERROR: No location specified or remembered
[16:04] <gabe> is that bad news?
[16:04] <lifeless> gabe: add the '.' :)
[16:04] <jam> gabe: there is a hard to see '.' after the revid
[16:04] <jam> you could alternatively change the order
[16:04] <jam> bzr merge . -r revid:.....
[16:05] <jam> lifeless: are you still in Europe?
[16:05] <gabe> lifeless: yep, quite right!
[16:05] <lifeless> jam: London indeed
[16:05] <lifeless> gabe: happy to help, sorry it took up your friends time
[16:05] <Odd_Bloke> abentley: https://bugs.launchpad.net/bundlebuggy/+bug/248422
[16:05] <jam> lifeless: how long before you head back to AU? (Just curious how much time you'll be awake when I am :)
[16:06] <abentley> Odd_Bloke: Was the patch merged after BB started tracking PQM?
[16:08] <lifeless> jam: 1 week
[16:09] <gabe> lifeless: we're still working on that last command
[16:10] <gabe> seems he gets
[16:10] <gabe> "'bzr" is not recognized as an internal or external command,
[16:10] <gabe> operable program or batch file.
[16:10] <lifeless> gabe: well, how does he run bzr normally ? :)
[16:10] <gabe> is that because windows doesn't recognise the quotes around the command?
[16:10] <lifeless> gabe: you shouldn't copy the quotes, they were to show you what to copy :)
[16:10] <gabe> he uses the bzr command but not with quotes around it I guess
[16:10] <gabe> oh woops
[16:12] <gabe> that worked
[16:13] <gabe> lifeless: when I work on a checkout make local commits, when I want to commit to repo sometime I need to bzr up, but then it wipes all my changes too - why does this happen?
[16:13] <lifeless> gabe: it does not wipe them away; you have to run 'bzr revert' to wipe them away
[16:13] <gabe> so what does it do with my local commits then?
[16:13] <gabe> and why are they 'taken away'?
[16:14] <lifeless> it puts them into a pending merge
[16:14] <lifeless> so that after the update, when yo commit they go into the master
[16:15] <lifeless> and they are taken away when you run 'bzr revert' because bzr revert removes pending merges
[16:15] <Odd_Bloke> abentley: I _think_ so, but I'll go and check timestamps.
[16:15] <gabe> but bzr st doesn't show them?
[16:16] <lifeless> gabe: bzr st will show them
[16:16] <gabe> i mean i thought merges didn't really happen with checkouts
[16:16] <lifeless> gabe: I assure you, he ran - 'bzr up' and then 'bzr revert'
[16:16] <lifeless> gabe: checkouts can totally do merges
[16:16] <gabe> ok, so in the future, when my local revisions appear to have been nuked what should be be looking at doing?
[16:16] <lifeless> gabe: dont run bzr revert after an update and they will never appear to have been nuked
[16:17] <gabe> mmm ok
[16:17] <Odd_Bloke> abentley: You sent the message to the ML about PQM now being managed by BB on the 9th, the merge happened on the 10th.
[16:17] <lifeless> 'bzr update && bzr revert' is guaranteed to give you a tree the same as the thing you have a checkout of.
[16:17] <lifeless> gabe: (&& means followed by)
[16:17] <gabe> ah ok
[16:18] <gabe> and then what did you do to fix that? merge the current tree with a previous version that included local commits?
[16:18] <lifeless> bzr update && bzr commit is guaranteed to commit your local edits to the thing you have a checkout of.
[16:18] <lifeless> yes, the use of heads --dead-only, and merge, is how we reinstated the local commits.
[16:19] <abentley> Odd_Bloke: I'm not sure when the last tweak of the merge-detection code happened.  It may have been afterward.
[16:22] <lifeless> jam: I am going to make the last node in a row be variable-sized
[16:22] <lifeless> jam: using b+tree indices in bzr search.. hurt
[16:23] <jam> lifeless: I understand your desire, but isn't that the last node in the *last* row only?
[16:23] <lifeless> jam: yes
[16:23] <gabe> i need to find out about bzr heads
[16:24] <gabe> bzr heads
[16:24] <gabe> bzr: ERROR: unknown command "heads"
[16:24] <gabe> even after doing:  sudo ./setup.py install
[16:24] <lifeless> jam: its actually really the use of many tiny indices *I think*
[16:24] <gabe> in the bzrtools extraction dir
[16:24] <lifeless> gabe: what path did it install into
[16:25] <jam> lifeless: you realize, that is probably sub-optimal from an FS perspective anyway
[16:25] <gabe> Writing /Library/Python/2.5/site-packages/BzrTools-1.5.0-py2.5.egg-info
[16:25] <jam> considering most FS have a minimum 4k page
[16:25] <lifeless> jam: they are in a pack
[16:25] <jam> lifeless: you are putting the indexes into a pack file... ok, I guess
[16:26] <lifeless> jam: better than 100000 files on disk :)
[16:26] <lifeless> jam: ask mtaylor how long the earlier editions took to delete an index :)
[16:26] <mtaylor> jam: oit was not pretty :)
[16:27] <jam> lifeless: because deleting required re-packing everything?
[16:27] <jam> sounds like a flag "deleted" case :)
[16:27] <lifeless> jam: no, because ext3 doesn't handle hundred's of thousands of files in a single directory gracefully
[16:28] <lifeless> jam: bzr-search doesn't delete stuff anyway
[16:28] <jam> ah, before the packing
[16:28] <jam> yeah, I seem to remember running into that in the past
[16:28] <jam> when we were working on medical images and dumped 100k files in a directory
[16:28] <jam> I had to write a custom script that used the raw C files to move them out
[16:29] <jam> the raw C *functions*
[16:29] <jam> because 'ls *' or python listdir() would just take forever to finish
[16:30] <gabe> ls /Library/Python/2.5/site-packages/bzrlib/plugins/bzrtools/
[16:30] <gabe> __init__.py             dotgraph.pyc            rspush.py
[16:30] <gabe> etc
[16:30] <gabe> seems to be there
[16:30] <jam> gabe: I would double check that "bzr --version" lists /Library/Python/2.5/site-packages/bzrlib as its bzrlib location
[16:31] <gabe> ha no
[16:31] <gabe> it doesn't
[16:31] <gabe> best fix that
[16:34] <jam> Odd_Bloke: still getting your random commits on the commit list
[16:34] <jam> http://bzr.daniel-watkins.co.uk/pqm/work/foo "renamed 'foo' => 'bar'"
[16:35] <meteoroid> i initialized a repository from generated code, added everything, committed, then branched to a remote bzr+ssh url.  this location on the server only ended up with a .bzr subfolder, and is smaller, significantly, than a branch made from it locally, eg. 'bzr branch main dev'
[16:35] <meteoroid> clearly there is something basic i don't understand, anyone care to proffer a link or something?
[16:35] <Odd_Bloke> jam: Ah, thanks.
[16:36] <jam> meteoroid: I'm guessing on your server you don't have a working tree, which is standard for places that we can't access the wt directly
[16:36] <jam> you should still have all the revision data
[16:36] <jam> just no working files
[16:36] <Odd_Bloke> If I have a lightweight 'work' checkout which is bound to a branch, which location's settings will be used from locations.conf?
[16:36] <meteoroid> jam: ah ok, that's what i figured, is there some command i run to turn a branch into a wt?
[16:36] <jam> Odd_Bloke: are you saying light weight => branch => other_branch ?
[16:36] <jam> meteoroid: 'bzr co'
[16:37] <jam> but the WT won't be updated by default either
[16:37] <jam> (there are some workarounds for this)
[16:37] <meteoroid> hm
[16:37] <meteoroid> well i shouldn't use the 'master' i set up as a wt anyway
[16:37] <meteoroid> actually i was kinda curious why the other branches were bigger
[16:37] <meteoroid> i guess i want to branch remotely
[16:38] <meteoroid> still have yet to set up http :/
[16:38] <Odd_Bloke> I have 'pqm/work' bound to 'pqm/foo'.  When I commit in 'pqm/work' (and so in 'pqm/foo') which config in locations.conf will be used, 'pqm/work's or 'pqm/foo's?
[16:38] <Odd_Bloke> jam: ^
[16:39] <jam> Odd_Bloke: that isn't a lightweight checkout...
[16:39] <jam> but I would guess if you have a bound 'work' => 'foo' then 'work' still gets used for the bound branch
[16:39] <gabe> lifeless: thanks ever so much for your help
[16:39] <jam> I'm not sure that all functions agree on this, though
[16:39] <lifeless> dato: ping
[16:39] <gabe> my friend is so relieved to have all his work back and is very grateful to you :)
[16:39] <lifeless> gabe: no probs
[16:40] <gabe> what is a revision that doesn't have descendents and is dead?
[16:41] <lifeless> gabe: a dead revision is one that no branch refers to
[16:41] <lifeless> gabe: a revision with no commits that build upon it is a head
[16:41] <Odd_Bloke> jam: It _is_ a lightweight checkout, I presumably didn't mean 'bound to'. :)
[16:41] <jam> Odd_Bloke: lightweight will use the target
[16:41] <gabe> and that is what you get if you do bzr up &&  bzr revert ?
[16:41] <jam> that I'm sure of
[16:42] <jam> when we open a light checkout, it instantly redirects to open the target branch
[16:42] <jam> so we don't really ever *see* the lightweights fake branch
[16:42] <jam> and almost all config is done at the Branch level, not the WT level
[16:42] <lifeless> gabe: yes
[16:48] <jam> lifeless: for the 'failure during deep copy' do you have any hints as to what happened?
[16:48] <jam> Did it just fail *to* deepcopy?
[16:48] <jam> (I'm testing with python 2.4.5 and things seem to work)
[16:48] <lifeless> it just failed to copy
[16:48] <lifeless> it was 2.4.4
[16:48] <lifeless> (manganese)
[16:50] <jelmer> lifeless, Odd_Bloke: Are you going to be around for some sprinting before saturday?
[16:50] <lifeless> jelmer: I'm in London, get to wolverhampton 9pm friday
[16:50] <jelmer> I'm in Dublin atm and trying to decide whether to go home for a day or two or to go there directly
[16:50] <jelmer> lifeless, ah, ok
[16:51] <lifeless> jelmer: if you wanted to come to London for a bit I'm sure that would be ok
[16:53] <jam> lifeless: well, the trivial "a = array.array(...); b = copy.deepcopy(a)" works on manganese :(
[16:53] <lifeless> jam: I was running 'bzr upgrade --btree-plain' with blooms enabled
[16:54] <lifeless> jam: and this made it fall down go boom
[16:54] <jelmer> lifeless, That may be a nice idea
[16:54] <lifeless> jelmer: let me confirm then
[16:54] <jam> I wonder if it might have been an OOM error
[16:55] <Odd_Bloke> jelmer: I'm in Coventry (at home) ATM.
[16:58] <lifeless> jelmer: yes, wouldn't be a problem for you to drop into the office; ned to know the days in advance though :)
[16:58] <lifeless> jam: don't think so
[16:58] <lifeless> jam: it had _much_ more meory problemms earlier when it was digging GB's into swap
[17:00] <jelmer> lifeless: cool, thanks. I'll see if I can figure out the travel
[17:00] <Odd_Bloke> jelmer: I don't have any solid committments this week, though, so I'm available for sprinting.
[17:00] <jam> lifeless: that is where you are testing the 1M keys ?
[17:01] <lifeless> jam: yeah, I have it in btree-plain now
[17:01] <jam> and if there is memory fragmentation, it is *possible* for it still to die if array's require contiguous memory
[17:01] <lifeless> jam: it was something about number pof parameters to a method I think
[17:02] <lifeless> jam: its 2.9M keys btw
[17:02] <lifeless> jam: look in ~robertc/megarepo/.bzr/repository/indices :)
[17:04] <jam> lifeless: we seem to have a 16GB pack file in there. I'm kind of happy to see that we support >4GB files :)
[17:04] <jam> though I wonder if we *really* want to :)
[17:05] <lifeless> jam: yes, otherwise latency++++
[17:06] <jelmer> Odd_Bloke: Ah, cool - how far are you from Wolverhampton?
[17:06] <jam> lifeless: so that is just an aggregate repo of a bunch of different projects, right?
[17:06] <lifeless> jam: oh, it was 2.5 that blew up
[17:07] <lifeless>     selected = min(candidates, key=getter)
[17:07] <lifeless> TypeError: min() takes no keyword arguments
[17:07] <lifeless> thats on 2.4
[17:07] <Odd_Bloke> jelmer: About an hour by train.
[17:08] <lifeless> jam: getting content out:
[17:08] <lifeless> time python2.5 bzr/bzr branch megarepo/pool/main/libj/libjpeg6b/
[17:08] <lifeless> real    0m5.365s
[17:08] <lifeless> then
[17:08] <lifeless> real    0m1.380s
[17:08] <lifeless> real    0m2.433s
[17:08] <lifeless> (the machine is being hammered right now :))
[17:09] <jam> lifeless: well, the 1.8G resident is a bit of an issue
[17:09] <lifeless> jam: thats the bzr search task
[17:09] <lifeless> jam: which is using GraphIndex still (see the 4K page thing I mentioned :))
[17:13] <jam> james_w: by the way, thanks a *ton* for doing all the work you've been doing on managing the bug tracker, it is really nice to have someone on top of it
[17:14] <james_w> no problem, I think there's quite a bit more to do to get importance/status assigned.
[17:15] <lifeless> mtaylor: ping
[17:15] <mtaylor> lifeless: pong
[17:15] <lifeless> mtaylor: you were working on server-side email right?
[17:15] <mtaylor> lifeless: was looking at it
[17:15] <lifeless> mtaylor: the savannah folk are looking for that : if you could put your branch up that would rock :)
[17:15] <mtaylor> lifeless: I settled on a modification of bzr-email though
[17:16] <mtaylor> lifeless: so I have nothing for them :(
[17:16] <lifeless> oh
[17:16] <lifeless> nuts :)
[17:16] <mtaylor> yeah
[17:16] <mtaylor> sorry
[17:16] <lifeless> is your modifcation general purpose? you could put it up anyhow :)
[17:56] <Odd_Bloke> jelmer, lifeless: I'm going out for the evening, let me know if anything transpires sprint-wise and I'll respond when I get back. :)
[17:57] <lifeless> Odd_Bloke: its up to jelmer really :)
[18:42] <Odd_Bloke> jelmer: Let me know. :)
[19:32] <agoebel> is there a way to have the webdav plugin handle authentication?
[19:53] <abentley> lifeless: ping
[19:56] <vila> agoebel: the webdav plugin handles authentication by relying on bzr http client implementation handling authentication :)
[19:57]  * vila ducks
[19:57] <agoebel> in which case why am I getting a "can't handle 401 auth required" response?
[19:59] <vila> either because you didn't specify user in url (http://user@host) or your password is wrong
[20:00] <agoebel> ah, missed the user
[20:00] <agoebel> figured it would give my a prompt
[20:00] <agoebel> thanks
[20:00] <vila> alternatively you can also use authentication.conf to provide user and/or password
[20:00] <LarstiQ> having it prompt would be real nice
[20:01] <vila> bug already filed (can't remember it right now, and I'm gone anyway :)
[20:17] <jelmer> Odd_Bloke, will do
[20:22] <dato> lifeless: pong
[20:34] <jelmer> lifeless, ping
[20:43] <colbrac> jelmer: Currently from olive pressing the push button in the push dialog succesfully pushes, but also gives a bzr-gtk error 'int argument required'
[20:43] <colbrac> jelmer: Any clue?
[20:43] <jelmer> colbrac: bzr-gtk probably expects the push function to return an integer
[20:44] <jelmer> whereas it returns an object these days
[20:44] <jelmer> PushResult I think
[20:44] <jelmer> See bzrlib.branch.Branch.push
[20:45] <colbrac> I see a 'rev = 0' a few lines higher yes
[20:45] <colbrac> where later try: rev = dopush()
[20:45] <jelmer> right, rev would actually be a PushResult object rather than the number of revisions pushed
[20:48] <colbrac> so, in the final lines of that method an info dialog is made with revs as the number of revs pushed
[20:49] <colbrac> how can I get that number from PushResult?
[20:49] <colbrac> (if you happen to know by heart) :)
[20:50] <colbrac> jelmer: The push you are pointing at says 'raise NotImplementedError(self.push)'
[20:50] <colbrac> :P
[20:50] <jelmer> colbrac: Well, that should have the API description
[20:51] <jelmer> See bzrlib.branch.PushResult for the object that's returned by push()
[20:53] <colbrac> hmm.. has deprecated all over it.. but should return the revno on initiation.. :/ Maybe not initiated anymore in bzr trunk?
[20:56] <jelmer> I don't see any deprecated stuff there
[20:56] <jelmer> what in particular are you referring to?
[20:57] <colbrac> I'm looking in bzr/trunk/bzrlib/branch.py line 2230: class PushResult
[20:58] <colbrac> But on a closer look of bzr-gtk/trunk/push.py, I don't see any bzrlib.branch imports
[20:58] <colbrac> bzr trunk as of yesterday
[20:58] <colbrac> bzr-gtk rev 531
[20:59] <jelmer> colbrac: that's because it already has a branch instance
[20:59] <jelmer> that gets passed to it
[20:59] <jelmer> there's no need for imports
[21:03] <colbrac> so.. if I read that do_push function correctly, the count var that is returned is not set when a correct branch_to location is given from the start?
[21:04] <colbrac> which explains the lack of an int
[21:07] <colbrac> jelmer: The count var is not set in do_push when the first try is succesfull
[21:14] <colbrac> jelmer: push to '../folder-that-didnt-exist' doesn't give the error, and a PushResult is returned
[21:28] <jelmer> colbrac: it is, see the "else:" clause
[21:29] <jelmer> the problem is the fact that br_to.pull() no longer returns an integer
[21:29] <colbrac> but check.. it does br_to.pull
[21:29] <colbrac> I saw
[21:30] <jelmer> Odd_Bloke,lifeless: I'll arrive on wednesday in London
[21:31] <jelmer> colbrac: Yeah, that's correct
[23:29] <lifeless> dato: I wanted to chat with you about the use of the index in git and what we might do similarly
[23:30] <lifeless> dato: but its way late for me now; perhaps tmorrow?
[23:30] <lifeless> night all
[23:30] <beuno> g'night lifeless
[23:30] <dato> lifeless: it's late here too :)
[23:30] <dato> but I'm only available evening UTC
[23:32]  * ToyKeeper would love to hear about that too
[23:38] <agoebel> does anyone have the trunk of bzr-gedit working with gedit 2.22.3?