[21:25] <lifeless> moin
[21:55] <vila> night ;)
[21:55] <lifeless> hah, my string.find() bug is getting 'me toos' :)\
[21:55] <lifeless> thanks for the email patch vila
[21:55] <vila> lifeless: you're welcome
[21:59] <jelmer> 'morning lifeless
[22:01] <lifeless> hi jelmer
[22:16] <vila> lifeless: when you say "This format was introduced in bzr.dev" you intend to update with the current bzr version when merging I hope ?
[22:16] <vila> s/merging/landing/
[22:17] <lifeless> yes
[22:32] <mtaylor> I'm getting this: bzr: ERROR: exceptions.MemoryError
[22:32] <mtaylor> when I try to do any bzr operations on a branch
[22:32] <mtaylor> using bzr 0.91 on gutsy
[22:35] <Odd_Bloke> mtaylor: That is normally a sign that there's a particularly large file in the branch.
[22:35] <mtaylor> Odd_Bloke: yeah - I shouldn't have any of those
[22:35] <mtaylor> Odd_Bloke: and it happens on bzr status, too
[22:35] <Odd_Bloke> mtaylor: No ulimits of any description?
[22:35] <mtaylor> Odd_Bloke: nope
[22:36] <mtaylor> the whole tree is at 11M
[22:36] <Odd_Bloke> mtaylor: Nothing else huge resident in memory?
[22:36] <mtaylor> and I get the memory error almost immediately
[22:36] <mtaylor> I have 786M free
[22:37] <mtaylor> I can try kiling firefox and eclipse
[22:38] <mtaylor> Odd_Bloke: now I have 1.6G free, and it still gives me the error
[22:38] <mtaylor> I've tried 0.90 and 0.91
[22:38] <mtaylor> both to no avail
[22:41] <mathrick> hey
[22:41] <mtaylor> Odd_Bloke: it's only in that one branch, too
[22:41] <mathrick> is there a way to see exactly what's causing rejects when unshelving?
[22:43] <Odd_Bloke> mtaylor: Has the branch ever had any large files committed but later removed?
[22:44] <mtaylor> Odd_Bloke: no.
[22:45] <Odd_Bloke> mtaylor: Does even 'bzr check' fail?
[22:45] <mtaylor> Odd_Bloke: bzr check works
[22:46] <mtaylor> Odd_Bloke: I'm able to branch from that branch and then operate in the new branch just fine
[22:47] <mtaylor> Odd_Bloke: but I can't run bzr diff to see if there were any uncommited changes in the old branch I'd forgotten about
[22:47] <Odd_Bloke> mtaylor: You could run a standard diff?
[22:48] <mtaylor> Odd_Bloke: yes. that works - except for needing to filter out all of the autoconf crap
[22:48] <mtaylor> :)
[22:48] <Odd_Bloke> mtaylor: Also, can you tar up the branch, and extract it elsewhere retaining the issues?
[22:48] <Odd_Bloke> mtaylor: Ah, yeah, that'd be a problem. :p
[22:48] <mtaylor> Odd_Bloke: well, it's in a local repository
[22:48] <mtaylor> Odd_Bloke: so I think if I tar up just the branch, it won't be complete, right?
[22:49] <mtaylor> Odd_Bloke: but I could try creating another repository, branching from one to the other to get the revisions and then copying over the borked branch
[22:50] <lifeless> wow
[22:50] <lifeless> mwhudson: mmm, its possibly a bug in diff matching, e.g. pythons standard libary at one point recursed waaaay to much
[22:50] <lifeless> mtaylor: ^
[22:50] <lifeless> sorry mwhudson :)
[22:50] <mtaylor> hm.
[22:51] <lifeless> mtaylor: is there a backtrace in ~/.bzr.log ?
[22:52] <mtaylor> lifeless: well, I get one on the screen
[22:52] <mtaylor> is there a pastebin somewhere I can stick it?
[22:52] <lifeless> sure
[22:52] <lifeless> http://rafb.net/paste
[22:53] <mtaylor> http://rafb.net/p/uUVwBB87.html
[22:56] <lifeless> ok
[22:56] <lifeless> this may be a C extension bug
[22:57] <lifeless> MemoryError may be sigsegv
[22:57] <lifeless> hmm, I'm not sure offhand of how to disable the C extensions in a packaged bzr
[22:57] <lifeless> so -
[22:58] <lifeless> _dirstate_helpers_c.so
[22:58] <lifeless> find that file
[22:58] <lifeless> (e.g. locate _...)
[22:58] <lifeless> rename it out of the way (as root)
[22:58] <lifeless> then try again
[22:59] <lifeless> mtaylor: ^
[22:59] <mtaylor> k
[23:00] <mtaylor> lifeless: now I get an AssertionError
[23:01] <mtaylor> http://rafb.net/p/3QbwaA82.html
[23:03] <lifeless> mtaylor: looks like a damaged dirstate file
[23:03] <lifeless> did you have a power failure or some such during commit, or si this on NFS?
[23:04] <mtaylor> lifeless: nope. not on nfs. and I don't remember any power failures
[23:04] <lifeless> anyhow, your current tree state has been damaged
[23:04] <mtaylor> lifeless: I did recently try to use the bzr eclipse plugin... perhaps that screwed something up
[23:04] <lifeless> it shouldn't be accessing this file directly
[23:04] <mtaylor> lifeless: ok. well I'll just browse around and look for uncommited changes
[23:05] <mtaylor> I don't think I had any
[23:05] <lifeless> you could try:
[23:05] <lifeless> bzr branch . ../clean
[23:05] <lifeless> diff -Nrup -x .bzr . ../clean
[23:05] <lifeless> [sorry that you're having to do this]
[23:05] <mtaylor> hey - no problem!
[23:06] <fullermd> You could tar up your working files, rm them and .bzr/checkout/, re-checkout the tree, blow away the files, and untar the old ones.
[23:06] <lifeless> fullermd: simpler:
[23:07] <lifeless> bzr branch . ../clean
[23:07] <fullermd> (I dunno if remove-tree would work if the checkout metafiles were wonky)
[23:07] <lifeless> cp ../clean/.bzr/checkout/dirstate .bzr/checkout/
[23:07] <lifeless> mtaylor: ^
[23:07] <lifeless> that will discard knowledge of renames
[23:07] <lifeless> and of pending merges
[23:07] <lifeless> but will be otherwise good
[23:08] <mtaylor> lifeless:  turns out I don't have any ditry files... so the bzr branch . ../clean
[23:09] <mtaylor> gives me a tree that's got everything
[23:09] <mtaylor> *phew*
[23:09] <mtaylor> now - if only I knew how the dirstate got screwed
[23:09] <lifeless> abentley: the graph is the problem, I'm adding a HeadsCache to graph.py
[23:10] <lifeless> abentley: we do 1M key lookups to commit a merge of bzr.dev.
[23:10] <abentley> Do we really need to be doing that many?
[23:10] <lifeless> one hopes not :)
[23:12] <mtaylor> lifeless: thanks for the help!
[23:12] <lifeless> https://bugs.edge.launchpad.net/bzr/+bug/153749
[23:12] <ubotu> Launchpad bug 153749 in bzr "dirstate C helper MemoryError on bad dirstate file" [Undecided,New]
[23:12] <lifeless> filed as a result of your problem
[23:12] <mtaylor> sweet. glad to help ;)
[23:13] <mtaylor> lifeless: would my working tree be helpful at all?
[23:13] <lifeless> uhm
[23:13] <mtaylor> I can tar it (and the repos it's in up) if it would be
[23:13] <lifeless> it *might* help figure out the nature of the corruption
[23:13] <lifeless> the only file we'd need is .bzr/checkout/dirstate
[23:13] <abentley> Well, I'm really asking if it's the caller's fault or the callee's fault.
[23:14] <lifeless> abentley: we do one heads() call per file being committed
[23:15] <mtaylor> HAHA
[23:16] <mtaylor> lifeless: you gotta love it when you get a launchpad oops while uploading an attachement to a bug :)
[23:16] <ekimus> hi, just wanted to start playing around with baraar and ubuntu/feisty has this in the description "Unless you have a pressing reason to use bazaar you should use some other revision control system as upstream development has ceased." - is that remotely true or just a bad incident that it is an outdated version?
[23:16] <Odd_Bloke> ekimus: You want 'bzr'.
[23:16] <mtaylor> ekimus: ^^
[23:17] <lifeless> mtaylor: we're having a postgresql glitch right now, admins are on it.
[23:17] <lifeless> mtaylor: just try again please :)
[23:17] <mtaylor> lifeless: it worked the second time
[23:17] <lifeless> ekimus: thats a bug in the packaging - the 'bazaar' package is not bzr. 'bzr' is the package name.
[23:17] <lifeless> mtaylor: cool
[23:17] <ekimus> Odd_Bloke: thanks, looks a lot better :)
[23:20] <ubotu> New bug: #153749 in bzr "dirstate C helper MemoryError on bad dirstate file" [Undecided,New] https://launchpad.net/bugs/153749
[23:43] <lifeless> abentley: its taking 10+ seconds to answer heads(('robertc@robertcollins.net-20071017014801-c6u8dl03zk1gko3r', 'andrew.bennetts@canonical.com-20071012052646-wl95idld3ijjy714')
[23:43] <lifeless> )
[23:43] <lifeless> abentley: so I'm thinking its graph's fault.
[23:45] <ekimus> hmm the bzr ignore is a per location setting/command right? (still scanning the docs and no hands on experience yet)
[23:47] <fullermd> ekimus: It gets set in the branch you run it in, yes (it all goes in a '.bzrignore' file in the root of the branch)
[23:48] <lifeless> ekimus: there is also a global ignore you can set
[23:48] <lifeless> in ~/.bazaar/bazaar.conf|locations.conf
[23:48] <lifeless> I should say 'local ignore'
[23:50] <ekimus> yup i can set the ignores in a central place but the setting is local to each repo (somehow like this should be correct)
[23:50] <lifeless> you can set ignores in three places:
[23:50] <lifeless> bazaar.conf
[23:50] <lifeless> affects all use of bzr on your machine
[23:50] <lifeless> locations.conf
[23:50] <lifeless> affects use of bzr by url matching
[23:50] <lifeless> .bzrignore
[23:50] <lifeless> affects that one branch
[23:51] <lifeless> (and propogates via merge operations to other branches)
[23:52] <fullermd> Don't you mean ~/.bazaar/ignore?
[23:52] <lifeless> oh, perhaps I'm confused
[23:52]  * fullermd didn't know you could set ignores in locations.conf...
[23:52] <lifeless> *ignore me*
[23:52] <fullermd> echo lifeless >> .bzrignore    8-}
[23:53] <lifeless> ekimus: generally though, its just 'bzr ignore NEWS' and it DTRT
[23:54] <ekimus> http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#ignore seems to be that a .bzignore file is used also (just thru the ignore command)
[23:54] <fullermd> Right.  'bzr ignore' just adds lines to the .bzrignore file in the branch.
[23:59] <ekimus> hmm something i'm missing is some more docs about the how to run a bzr:// server and what options there are for access control. then again, a) i just have to try it b) it's python and the hooks seem to be easy to do (if they are as simple as plugins - which i just found out that i read the docs for instead of hooks)