[12:14] <lifeless> igc:  can you merge my bytes_to_gzip patch?, I'm definite its the right thing now even with memory copies - 3 seconds win with it
[12:14] <lifeless> igc: even with my faster-sha patch
[12:14] <igc> sure. I'll do that RSN
[12:31] <ubotu> New bug: #141382 in bzr "Test failures when TMPDIR points at a symlink" [Low,New]  https://launchpad.net/bugs/141382
[12:33] <lifeless> igc: thanks!
[12:33] <lifeless> igc: I've decided path_content_summary is the go
[12:34] <igc> Yes, I think it is
[12:34] <lifeless> igc: it may be wrong eventually but for now its an improvement, IFF I add the sha lookup
[12:34] <lifeless> so I'm going to add that today
[12:34] <igc> 4% review just sent to the list btw
[12:35] <igc> so lifeless, you have a lot of merges needed to pqm :-)
[12:35] <igc> I can do most of them today if you wish
[12:35] <igc> what order do you want them submitted if any?
[12:36] <lifeless> make bytes would be a good start
[01:05] <lifeless> jelmer: what bug is your bundle on ?
[01:06] <jelmer> lifeless, which bundle?
[01:06] <lifeless> the pqm one
[01:06] <lifeless> I'm looking at bug 117197
[01:06] <ubotu> Launchpad bug 117197 in pqm "Doesn't install required Python package" [High,Triaged]  https://launchpad.net/bugs/117197
[01:06] <lifeless> but theres no linked branch or bundle
[01:07] <jelmer> lifeless: oh, I send the bundle to you. I'll attach it to the bug report, didn't know that was actually open
[01:07] <jelmer> s/send/sent/
[01:07] <lifeless> you filed it :)
[01:08] <jelmer> whoops, that's the second time that happens
[01:09] <jelmer> ok, bundle is now attached
[01:27] <lifeless> igc just had a power failure
[01:42] <kkubasik> hey, I just found bug# 133989
[01:42] <kkubasik> its where bzr cant branch from svn on windows
[01:43] <kkubasik> with a FleExitst error
[01:43] <kkubasik> has anyone heard anything as far as possible solutions etc?
[01:47] <jelmer> kkubasik, that's a bug in bzr's windows support
[01:47] <lifeless> jelmer: are you sure?
[01:47] <lifeless> jelmer: I thought so too, but only bzr-svn users seem to hit it
[01:47] <jelmer> lifeless, yes, it was also reported independently against bzr
[01:47] <lifeless> oh ok
[01:47] <kkubasik> ahhh
[01:47] <lifeless> do we know the cause yet? is it a change in python ?
[01:48] <lifeless> kkubasik: this is recent FWIW
[01:48] <jelmer> https://bugs.edge.launchpad.net/bzr/+bug/139253
[01:48] <ubotu> Launchpad bug 139253 in bzr "bzr branch fails with "File exists" error." [Undecided,New] 
[01:48] <lifeless> bump that to critical please
[01:48] <lifeless> and triaged
[01:48] <jelmer> done
[01:49] <lifeless> user    1m20.565s
[01:49] <lifeless> commit is sneaking down still :)
[01:49] <jelmer> lifeless: which tree?
[01:50] <lifeless> moz
[01:50] <lifeless> initial
[01:50] <jelmer> nice
[01:50] <lifeless> (I'm working on incremental, but have to run the initial each time as well to stop regressions)
[01:51] <jelmer> as everything else seems to be fast enough nowadays :-)
[01:51] <elmo> I remember when status took that long for one file in the moz tree :-P
[01:51] <elmo> \o/
[01:52] <lifeless> elmo: initial commit in bzr.dev is 3m20 user
[01:53] <lifeless> elmo: and 6+minutes wallclock
[01:53] <elmo> what's the wall for you commit?
[01:53] <lifeless> I get
[01:53] <lifeless> real    1m26.859s
[01:53] <lifeless> user    1m20.565s
[01:53] <lifeless> sys     0m4.420s
[01:53] <elmo> nice
[01:53] <lifeless> packs: )
[01:53] <lifeless> whenever linux is slow, write your own filesystem FTW
[01:53] <elmo> (and I was just being bitter - I have too many machines running bzr 0.8)
[01:54] <poolie> elmo, that's the dapper version?
[01:55] <lifeless> poolie: yes
[01:55] <lifeless> we have not done an SRU yet
[01:55] <poolie> good morning lifeless
[01:56] <lifeless> hi poolie
[01:56] <lifeless> igc has had a power failure
[01:57] <poolie> :)
[01:57] <poolie> Brisbane was famous for power failures when i was a kid
[02:00] <lifeless> poolie: bzrlib/tests/inventory_implementations/basics.py
[02:00] <lifeless> is named strangely, why isn't it test_basics.py ?
[02:00] <poolie> no good reason
[02:07] <igc> I'm back
[02:17] <lifeless> thanks jelmer that was very helpful
[02:18] <lifeless> igc: my patch for rename correctness isn't merged
[02:18] <lifeless> igc: if it was approved, could you merge that too ?
[02:18] <igc> sure
[02:18] <igc> just doing the 4% one now
[02:22] <lifeless> vila: please keep news alphabetically sorted now
[02:22] <lifeless> vila: as per the thread on the list
[02:23] <lifeless> F comes after H
[02:23] <lifeless> in NEWS, but shouldn't
[02:23] <jdong> wait, F doesn't come before H
[02:23] <jdong> oh nvm
[02:23] <jdong> just... please... hit /clear and pretend that never happened :)
[02:27] <lifeless> poolie: pushing 2768 of repository branch
[02:27] <lifeless> poolie: its up to date with bzr.dev some more with that
[02:28] <poolie> everyone's beeping at me
[03:22] <igc> lifeless: rename_one fix submitted to pqm now fyi
[03:22] <lifeless> danke
[03:30] <lifeless> elmo: btw why don't you upgrade bzr across all the systems
[03:30] <lifeless> elmo: there are many bug fixes you should really have
[03:32] <Vantage13> hi I'm using bzr 0.18 with bzr-cvsps-import and it keeps throwing memory errors on cvs v files that are larger than 20MB.  Is there any way at all around this? (aside from adding more ram...)
[03:33] <lifeless> Vantage13: theres no existing knob that I'm aware of. Can you please file a bug on this; and if you know some python I'd be happy to help you work up a patch to fix this
[03:33] <Vantage13> lifeless: is this a bzr-cvsps-import bug or bzr itself?
[03:34] <lifeless> Vantage13: I would say bzr-vcsps-import
[03:49] <lifeless> lol
[03:49] <lifeless> knits$ bzr vommit
[03:49] <lifeless> bzr: ERROR: unknown command "vommit"
[03:49] <jdong> now we need to implement it :)
[03:50] <jdong> Spec: Bulimic Repacker: bzr vomit / bzr gag....
[03:58] <lifeless> spiv: ping
[03:59] <fullermd> Hm.  'vomit' should be an alias for 'uncommit'...
[03:59] <spiv> lifeless: pong
[04:10] <lifeless> spiv: hows teh fix? Can we chat about it?
[04:10] <spiv> Sure.
[04:11] <spiv> (you mean on phone or here?)
[04:11] <lifeless> either
[04:11] <igc> lifeless: review of 40% one done now
[04:11] <lifeless> phone focuses the mind
[04:13] <spiv> Basically it's working, but the tests are a PITA.  It's awkward to construct broken versionedfiles to run the tests on.  I have an automated test for it, but the scaffolding is a bit ugly.
[04:14] <spiv> I think it's probably time I fired it off to the list for review despite that.
[04:16] <ubotu> New bug: #141411 in bzr-cvsps-import "Import fails with memory error on files larger than 25MB" [Undecided,New]  https://launchpad.net/bugs/141411
[04:16] <lifeless> spiv: how about a phone chat then, see if we can find a way to express the problem with test approach
[04:17] <spiv> lifeless: sounds good.
[04:35] <Vantage13> anyone know what alterations I'd have to make to remove a file or have bzr-cvsps-import skip a file?  I tried removing the cvs v file, and removing it from the CVSROOT commitlog but it still seems to know the file is missing and error out...
[04:52] <lifeless>         head_set = self._repo_graph.heads(parent_candiate_entries.keys())
[04:52] <lifeless>         heads = [] 
[04:52] <lifeless>         for inv in parent_invs:
[04:52] <lifeless>             if ie.file_id in inv:
[04:52] <lifeless>                 old_rev = inv[ie.file_id] .revision
[04:52] <lifeless>                 if old_rev in head_set:
[04:52] <lifeless>                     heads.append(inv[ie.file_id] .revision)
[04:52] <lifeless>                     head_set.remove(inv[ie.file_id] .revision)
[04:55] <lifeless> correct_parent_versions = [parent_version for parent_version in all_parent_versions in parent_version in g.heads(all_parent_versions)] 
[05:23] <cory> I haven't seen much in the way of bzr <-> p4.  Is there any hope of something saving me from this predicament? :P
[05:25] <lifeless> I've heard rumours, but not seen any code
[05:26] <lifeless> Vantage13: hi
[05:26] <lifeless> Vantage13: looking at the backtrace, I wonder if its a bug in our patiencediff.
[05:27] <lifeless> Vantage13: you could breakpoint in line 608 of knit.py to get the texts that are being diffed
[05:27] <lifeless> (_get_matching_blocks() does a diff)
[05:27] <cory> Hmm, rumors are better than nothing, I suppose.  tailor explodes in numerous different ways, and only deals with part of what I need.
[05:28] <cory> breakpoint... .py...how do you guys debug?
[05:28] <lifeless> breakpoints, logs, traceing, debug output
[05:29] <lifeless> pdb is a very good tool
[05:29] <cory> Hmm, wow.  I've never used pdb.
[05:29] <lifeless> put
[05:29] <lifeless> import pdb;pdb.set_trace()
[05:29] <lifeless> in a .py file somewhere, you'll get the hang of it easily
[05:32] <Vantage13> lifeless: I know the file that's causing the problem.  It's a large data import text file.  The diff between the two versions is pretty huge
[05:33] <lifeless> Vantage13: right, I'm wondering if the memory problem is not (its a 25Mb file), but (these two texts cannot diff properly with bzrlib)
[05:38] <Vantage13> lifeless: how do you insert a breakpoint there?
[05:38] <lifeless> import pdb;pdb.set_trace()
[06:00] <lifeless> ok, I can pull bzr.dev now, with the fix to not propogate parent corruption
[06:01] <igc> good news. I'm just merging your 40% one now btw
[06:01] <lifeless> thanks!
[06:01] <igc> but there are plenty others of yours in BB still to merge :-)
[06:09] <Vantage13> lifeless: around?
[06:10] <lifeless> Vantage13: yes
[06:11] <Vantage13> lifeless: so I've set_trace right before the loop and it's stopped, however, i'm not sure what I should be doing at this point or what I should be looking for
[06:11] <lifeless> well
[06:11] <lifeless> it probably will pass some number of times
[06:11] <lifeless> so 'c'
[06:12] <lifeless> many times until it crashes, then you can add a condition to only break into the debugger on that case
[06:12] <Vantage13> lifeless: i've actually got it on the one that crashes (since the previous calls were correctly processed the first time)
[06:12] <lifeless> ok cool
[06:12] <lifeless> you should have two texts there
[06:13] <Vantage13> I have
[06:13] <Vantage13>  /usr/lib/python2.4/site-packages/bzrlib/knit.py(609)_merge_annotations()-> for i, j, n in seq.get_matching_blocks():
[06:13] <Vantage13> and the prompt
[06:16] <lifeless> ok, one sec
[06:16] <Vantage13> k
[06:16] <lifeless> print annotated
[06:16] <lifeless> print parents
[06:16] <lifeless> print len(merge_content.text())
[06:16] <Vantage13> both are True
[06:17] <lifeless> print len (content.text())
[06:17] <Vantage13> 768676
[06:17] <lifeless> hmm, parents should be a list, not a boolean
[06:17] <Vantage13> 770413
[06:17] <lifeless> wow, thats quite long :)
[06:17] <lifeless> have a look via top - how much memory is the process using at the moment
[06:17] <Vantage13> lifeless: yeah, as I said :)
[06:18] <Vantage13> 17.8%
[06:18] <lifeless> however we do diff entire iso's using this code
[06:18] <lifeless> 17% of what ?
[06:18] <Vantage13> 370m Virt
[06:18] <Vantage13> sorry, I just grabbed the %MEM column
[06:18] <Vantage13> 360m RES
[06:18] <lifeless> ok, large but not insane
[06:18] <lifeless> (given the size of thing you are dealing with)
[06:19] <lifeless> lets save these two texts
[06:20] <Vantage13> lifeless: save how?
[06:20] <lifeless> bzrlib.transport.get_transport('file:///tmp/').put_bytes('a', ''.join(merge_content.text()))
[06:20] <lifeless> bzrlib.transport.get_transport('file:///tmp/').put_bytes('b', ''.join(content.text()))
[06:20] <lifeless> that should create two files on disk - check they exist and look ok to you
[06:20] <Vantage13> yup
[06:21] <lifeless> from a shell
[06:22] <lifeless> do python -m bzrlib.patiencediff /tmp/a /tmp/b
[06:22] <lifeless> theory is that this will blow up
[06:24] <Vantage13> odd.  It's saying module bzrlib.patiencediff not found, even though it is...
[06:24] <lifeless> ok
[06:24] <lifeless> just do /path/to/bzrlib/patiencediff.py /tmp/a /tmp/b
[06:26] <Vantage13> running...
[06:27] <lifeless> have a look in top, is it growing ?
[06:28] <Vantage13> at the moment, no.  It seems fixed at 170m
[06:29] <lifeless> how big is each file ?
[06:29] <Vantage13> 18M each
[06:30] <lifeless> so 36M from 170 134
[06:30] <lifeless> 370M + 134 = 504M
[06:34] <Vantage13> lifeless: this was the last message I got from you "370M + 134 = 504M".  was that the last one you sent?
[06:34] <lifeless> 14:30 < lifeless> which is big, how much ram do you have ?
[06:35] <Vantage13> lifeless: the machine has 2GB
[06:43] <lifeless> ok
[06:43] <lifeless> did it finish the diff ok ?
[06:43] <Vantage13> yup
[06:50] <lifeless> strange
[06:50] <lifeless> so if you step through the loop
[06:50] <lifeless> where does it crash
[06:53] <Vantage13> len(self.a), len(self.b), matches, 10)
[06:53] <Vantage13> MemoryError: <exceptions.MemoryError instance at 0xb7e2cd0c>> /usr/lib/python2.4/site-packages/bzrlib/patiencediff.py(244)get_matching_blocks()
[06:53] <lifeless> hmm
[06:53] <lifeless> and its on that pass through
[06:53] <lifeless> ?
[06:54] <Vantage13> then continuing through I also get
[06:54] <Vantage13> len(self.a), len(self.b), matches, 10)
[06:54] <lifeless> have you run out of memory now ?
[06:54] <Vantage13> MemoryError: <exceptions.MemoryError instance at 0xb7e2cd0c>> /usr/lib/python2.4/site-packages/bzrlib/knit.py(609)_merge_annotations()
[06:54] <lifeless> yea the exception is being raised frame by frame
[06:54] <lifeless> what does top show now ?
[06:55] <Vantage13> 397m
[06:55] <lifeless> still not enough to get OOM
[06:55] <lifeless> I have to pop away for a bit;
[06:56] <lifeless> basically we need to figure out what is causing the error
[06:56] <lifeless> I'd try stepping (s) into the function that fails now
[06:56] <lifeless> try to get to the point that the next 's' will cause a failure
[06:57] <lifeless> then investigate the variable etc that are involved and see if any are obscenely large or anything like that
[07:04] <Vantage13> lifeless: this seems to be the loop
[07:05] <Vantage13> 48  ->     for i in xrange(len(a)): 49             line = a[i]  50             if line in index: 51                 index[line]  = None 52             else: 53                 index[line] = i
[07:05] <Vantage13> in patiencediff.py
[07:07] <ssokolow> Does anyone know of a Bazaar cheat sheet similar to the Mercurial one and the edit of the Mercurial one to describe Git made by Zack Rusin?
[07:08] <poolie_> ssokolow, http://doc.bazaar-vcs.org/bzr.dev/en/quick-reference/quick-start-summary.svg
[07:08] <ssokolow> poolie_: Thanks.
[07:09] <poolie_> you're welcome
[07:10] <lifeless> Vantage13: so this should shrink memory use
[07:10] <lifeless> I think
[07:15] <Vantage13> lifeless: ?
[07:15] <lifeless> Vantage13: can you identify the exact point it fails ?
[07:16] <Vantage13> lifeless: without stepping through every single entry in file?  Probably not...
[07:16] <lifeless> yah
[07:17] <lifeless> uhm
[07:17] <lifeless> add a print i
[07:17] <lifeless> in there
[07:17] <lifeless> run to failure,
[07:17] <lifeless> then you can add a if i == failure_value: import pdb;pdb.set_trace()
[07:21] <igc> lifeless: that 40% one now merged into bzr.dev. Can you please check you're happy with how I merged & tweaked it?
[07:22] <lifeless> am doing
[07:22] <igc> thanks
[07:24] <Vantage13> lifeless: ok, i'm there
[07:24] <lifeless> so in theory, 's' will cause a crash
[07:25] <lifeless> does it ?
[07:25] <Vantage13> index[line] = i
[07:25] <Vantage13> throws the memory error
[07:26] <Vantage13> i=699050
[07:27] <Vantage13> line = V3S 6V2,BC,Surrey,1
[07:27] <Vantage13> is there a limit to the size of the data structure index?
[07:28] <lifeless> ok
[07:28] <lifeless> lets get back there
[07:28] <lifeless> and we won't run that line :)
[07:28] <lifeless> if your memory use is reasonable at this point I'm going to consider it a CPython bug probably
[07:28] <lifeless> >>> print type(index)
[07:28] <Vantage13> 'dict'
[07:30] <Vantage13> how do you print the total number of entries in the dictionary?
[07:31] <jml> len(index)
[07:31] <lifeless> print repr(line)
[07:31] <lifeless> lets be sure there's no funky business
[07:32] <Vantage13> 'V3S 6V2,BC,Surrey,1\r\n'
[07:32] <lifeless> so I think you have found a bug in python.
[07:32] <lifeless> whats the process size ?
[07:32] <Vantage13> 397m VIRT, 386m RES
[07:32] <lifeless> yah
[07:33] <lifeless> jml: what do you think? 'index[line]  = i' throws a MemoryError
[07:33] <jml> lifeless: "weird".
[07:34] <lifeless> I recall spiv tracking down a bug in dict
[07:34] <jml> Vantage13: print len(index)
[07:34] <lifeless> this may be it
[07:34] <spiv> lifeless: did I?
[07:34] <jml> lifeless: yeah, that rings bells.
[07:34] <Vantage13> 699051
[07:34] <spiv> I don't remember it :)
[07:34] <lifeless> spiv: in launchpad, some time back
[07:34] <lifeless> or perhaps it was jamesh, but I thought it was you
[07:34] <jml> hmm
[07:35] <spiv> Hmm, I do remember spending a lot of time digging through the dictobject.c code at some point.
[07:35] <spiv> I forget why though.
[07:36] <lifeless> rotfl
[07:36] <spiv> Something involving the difference between how it handled string keys (which it special cases) and other things.
[07:36] <lifeless> lifeless, spivs exomemory
[07:36] <lifeless> spiv: oh, perhaps it was security proxies as keys
[07:36] <lifeless> or something like tha
[07:36] <lifeless> so its bizarre to get an Out of memory error at this point
[07:37] <spiv> lifeless: oh, I do remember that bug sort of now.
[07:37] <lifeless> there is 400Mb in the process
[07:37] <spiv> lifeless: it wasn't a bug in dict, it just looked like it.
[07:37] <lifeless> this line is putting line into into
[07:37] <spiv> There was a __del__ somewhere deleting things from a dict when I didn't realise it.
[07:37] <spiv> Anyway, this is a large dict.
[07:37] <lifeless> Vantage13: can you do 'print line in index'
[07:37] <spiv> And inserting in a dict occasionally will trigger a resize.
[07:38] <lifeless> spiv: power of two expansion ?
[07:38] <Vantage13> lifeless: True
[07:38] <spiv> Which I believe happens by allocating a whole new table, moving stuff into the new table, then removing the old table.
[07:38] <lifeless> spiv: ^ line is already in there
[07:38] <spiv> Yeah, I think it's power of two.
[07:38] <lifeless> spiv: worst case it would allocate 800M (twice current memory), for 1.2Gb, still well within comfort - this machine has 2GB
[07:38] <lifeless> Vantage13: do you have ulimits in place ?
[07:38] <spiv> It has a loop doing "newsize <<= 1".
[07:39] <Vantage13> lifeless: nope.  unlimited
[07:40] <Vantage13> wait
[07:40] <Vantage13> virtual memory seems to have one...
[07:40] <Vantage13> suspiciously set to 409600
[07:40] <lifeless> ahha!
[07:40] <lifeless> there we go, memo to self, check ulimits earlier
[07:41] <spiv> lifeless: I don't see why you say the line is already in there; Vantage13 says "index[line] = i" is triggering the memory error after all.
[07:41] <lifeless> 15:37 < lifeless> Vantage13: can you do 'print line in index'
[07:41] <lifeless> 15:38 < Vantage13> lifeless: True
[07:41] <spiv> Ah, ulimits.
[07:41] <lifeless> I've quoted the two lines that make me say the line is already in there
[07:42] <spiv> lifeless: ah, I missed that, thanks.
[07:43] <lifeless> Vantage13: so, remove the debug statements and try again. I wager it will work
[07:43] <Vantage13> any idea off hand what would be setting that ulimit?  I assume it's a boot or login script...
[07:43] <lifeless> uhm /etc/defaults/ may have something
[07:43] <lifeless> theres also bash .d stuff in /etc/somethingorother
[08:03] <igc> lifeless: are you good to merge now or shall I keep helping? If so, I'll merge "micro-tweaks to sha routines" next assuming you still want it in
[08:03] <Vantage13> lifeless: we seem to have moved past that file, so i'm thinking that was it
[08:04] <lifeless> Vantage13: :)
[08:04] <Vantage13> lifeless: Thanks for all the help!
[08:04] <lifeless> igc: please merge it, I'm good but help is help.
[08:04] <igc> no problem
[08:05] <poolie_> lifeless, is that a 'tweak' vote for the traceback change?
[08:05] <poolie_> ie can i merge it with that change?
[08:05] <lifeless> poolie_: sure
[08:05] <lifeless> if my arguments are cogent
[08:05] <lifeless> and you are convinced
[08:06] <poolie_> sure, i just was being lazy
[08:06] <lifeless> :)
[08:06] <poolie_> succesfully
[08:08] <james_w> ulimits are set in /etc/security/limits.conf as well
[08:27] <lifeless> igc: a review of my knit random id patch would be cool too
[08:27] <igc> I'm doing it now
[08:27] <lifeless> :)
[08:27] <lifeless> I'm just benching all my combined changes finally
[08:28] <lifeless> I had *too many* branches to deal for a bit there
[08:28] <igc> :-)
[08:28] <igc> Hence my keenness today to get bzr.dev up to date
[08:28] <lifeless> its still not quite *all* branches
[08:28] <lifeless> but much closer
[08:29] <lifeless> initial commit figures
[08:29] <lifeless> real    1m28.816s
[08:29] <igc> so lifeless, I'm confused re that patch ...
[08:29] <lifeless> user    1m20.373s
[08:29] <lifeless> sys     0m4.572s
[08:29] <lifeless> which is good
[08:29] <lifeless> no regression
[08:30] <lifeless> mmmhmm ?
[08:30] <igc> the changes to _add() don't make any sense
[08:30] <lifeless> *blink*
[08:30] <igc> add_version gaining random_id I get
[08:30] <lifeless> really?
[08:31] <igc> but nothing in that patch calls _add
[08:31] <igc> is it already called by existing code?
[08:31] <lifeless> incremental with 5 new files,
[08:31] <lifeless> real    0m56.226s
[08:31] <lifeless> user    0m49.507s
[08:31] <lifeless> sys     0m3.744s
[08:31] <lifeless> and incremental with specified file
[08:31] <lifeless> real    0m23.494s
[08:31] <lifeless> user    0m22.117s
[08:31] <lifeless> sys     0m0.872s
[08:31] <igc> big difference there
[08:32] <lifeless> @@ -828,7 +828,7 @@
[08:32] <lifeless>          self._check_add(version_id, lines, random_id, check_content)
[08:32] <lifeless>          self._check_versions_present(parents)
[08:32] <lifeless>          return self._add(version_id, lines[:] , parents, self.delta,
[08:32] <lifeless> -            parent_texts, left_matching_blocks, nostore_sha)
[08:32] <lifeless> +            parent_texts, left_matching_blocks, nostore_sha, random_id)
[08:32] <lifeless> that hunk calls add
[08:32] <lifeless> but I missed a hunk in my edits
[08:32] <lifeless> I'll resubmit in a second
[08:32] <igc> I was about to say "sure - but what calls it?"
[08:33] <igc> :-)
[08:33] <lifeless> _add is called there
[08:33] <lifeless> or do you mean add_versions ?
[08:33] <igc> cool
[08:33] <igc> now, add_versions makes sense
[08:33] <igc> s/now/no/
[08:35] <lifeless> just supersede that path
[08:35] <lifeless> patch
[08:37] <lifeless> sent
[08:38] <igc> thanks
[08:39] <lifeless> bbiab
[08:47] <igc> that's all good now lifeless
[08:48] <poolie_> lifeless, would suggest renaming random_id to something that doesn't look like it's a random id
[08:49] <poolie_> like id_is_random
[08:52] <lifeless> poolie_: good suggestion; there is a idiom in play so we should do it for more than this one patch
[08:52] <lifeless> igc: is that +1 ?
[08:53] <igc> yep - voted on BB. I like poolie's suggestin btw but ...
[08:53] <igc> we've used random_id elsewhere so ..
[08:53] <igc> at least it's consistent
[08:53] <poolie_> can you search and replace for the others?
[08:53] <lifeless> monday perhaps
[08:54] <lifeless> going on 11 hours work today
[08:54] <poolie_> sure
[08:54] <igc> poolie_: time for some Qs?
[08:54] <igc> re bzrdir.py changes?
[08:54] <lifeless> so I'm inclined to merge this as is as igc was happy
[08:54] <igc> I'm not sure I understood your feedback in the review (poolie)
[08:55] <poolie_> i don't believe i did review it other than here
[08:55] <igc> as far as the new exception goes, better to report it than fail silently yes?
[08:55] <igc> yes you did
[08:55] <poolie_> which review?
[08:56] <igc> http://bundlebuggy.aaronbentley.com/request/%3C46EF7C4F.8020404%40internode.on.net%3E
[08:56] <lifeless> mmm too tired; going to leave this for monday
[08:56] <poolie_> have a good weekend
[08:56] <poolie_> are you going camping?
[08:56] <igc> ditto
[08:56] <lifeless> I've cancel codecon
[08:57] <lifeless> going to sleep
[08:57] <lifeless> I'm not good company right now
[08:57] <igc> sleep always helps I find :-)
[08:57] <lifeless> I may be fighting something off, feel *so* lethargic its not funny
[08:57] <poolie_> igc, are you talking about the last comment in that review?
[08:57] <igc> yep
[08:58] <igc> but all 3 need some discudssion :-)
[08:58] <poolie_> give me a minute
[09:02] <igc> so, I'm not convinced (yet) that initialize_on_transport should take possible_transports as a parameter ...
[09:02] <igc> what exactly does that buy us?
[09:03] <igc> By then, the transport has been selected, yes?
[09:03] <poolie_> igc, hi
[09:04] <igc> hi
[09:04] <poolie_> i looked at it again too, i don't think there's any point in passing it down
[09:04] <poolie_> so nevermind that
[09:04] <lifeless> poolie_: I've pushed up a bunch of merges today; you might like to see if that merges cleanly to your branch. I will look at your bundle monday.
[09:04] <poolie_> i'll send an update with more
[09:05] <igc> ok - so the exception feedback ...
[09:05] <igc> I've added a new exception that will get reported ..
[09:05] <igc> previously it failed but did nothing
[09:05] <igc> so I don't understand ...
[09:05] <igc> what you meant by 're-raise the orginal'
[09:06] <poolie_> something like this:
[09:06] <poolie_> i = 0
[09:06] <poolie_> while True:
[09:06] <poolie_>    rename
[09:06] <poolie_> feh
[09:06] <poolie_> hard to get it right in irc
[09:06] <poolie_> i meant that for the first n iterations, when an exception is raised, you should ignore it and try again
[09:07] <poolie_> after that, you should execute a bare 'raise' statement, causing it to rethrow the exception
[09:07] <igc> ah - ok
[09:07] <poolie_> so the caller, or the user, will see 'rename ............ failed: reason'
[09:07] <poolie_> which i think is just as clear
[09:07] <poolie_> unless i missed osmethigt
[09:07] <poolie_> something
[09:07] <igc> that's much clearer - thanks
[09:08] <igc> ok - last bit ...
[09:08] <igc> vila's code that isn't being used ...
[09:08] <igc> I'm just commenting out dead code
[09:08] <poolie_> ok, i think i understand it now
[09:08] <igc> well ...
[09:08] <igc> dead as in "pending" ...
[09:09] <poolie_> it's about, say, if it was http+pycurl then we should preserve the 'pycurl' bit
[09:09] <igc> when vila get's to it
[09:09] <poolie_> hm
[09:10] <poolie_> i think the main thing is that it ought to be a call to something like
[09:10] <poolie_> target = urlutils.copy_url_qualifiers(original, target)
[09:10] <poolie_> and then that can be tested separately
[09:10] <poolie_> rather than doing string slicing inline here
[09:11] <igc> yes, that's looks better
[09:11] <lifeless> I'm gone
[09:11] <lifeless> ciao
[09:11] <igc> I'd like to put in that line but not write it
[09:11] <igc> seeya lifeless
[09:11] <poolie_> put it in as a comment?
[09:11] <igc> yes ...
[09:11] <poolie_> ok with me
[09:11] <igc> thanks
[09:11] <igc> (just trying to keep semi-focussed)
[09:12] <igc> I'll put an updated patch up
[09:12] <vila> poolie_, igc: I agree with poolie about passing possible_transports down, at that paticular point (initialize) it's harmless to not passing it down
[09:13] <poolie_> but in general we should, right?
[09:13] <igc> yes
[09:13] <vila> poolie_: yes
[09:13] <poolie_> hello vila
[09:13] <vila> hi poolie_ , hi all ;-)
[09:13] <igc> good to chat with you vila!
[09:13] <vila> same here :)
[09:13] <igc> how's sunny France?
[09:14] <vila> been averbooked since I came back from vacations, thins have settled down a bit :)
[09:14] <vila> s/aver/over/
[09:14] <vila> s/thins/things/
[09:14] <igc> sounds pretty normal! :-)
[09:15] <vila> yeah, I didn't get 3 and 1/2 weeks in a row for years, that was very good but the come back was harder than expected :D
[09:15] <igc> yes, 2 weeks is the limit for most of us ...
[09:16] <igc> beyond that, it becomes "what am I doing with my life!!!" :- ):-)
[09:16] <vila> about the commented out code, I agree with lifeless, I hate it when people use a VCS and insist on commenting code out, plus there is already a bug for that
[09:16] <igc> vila: know the bug #
[09:17] <igc> ?
[09:17] <igc> if so, I'll update it with poolie's code suggestion
[09:18] <poolie_> vila, 3.5 weeks sounds nice, did you go away or just relax?
[09:18] <vila> #122258 is realted, not exactly the bug in question but strongly related
[09:18] <vila> poolie_: I went in spain and in several locations in France, we nearly saw all our best friends (some we didn't for years :)
[09:19] <vila> poolie_: but we relax a lot too :)
[09:19] <igc> sounds great
[09:20] <vila> we were so lucky, the summer was exceptionally bad this year, but we manage to get sun every day :) Every time we arrived somewhere people said: "Wow, you're lucky, the weather have been sooo bad until today/yesterday/a few minutes ago"...
[09:21] <igc> you must be good luck!
[09:24] <vila> ubugtu ? bug #122258 is related, not exactly the bug in question but strongly related
[09:24] <ubotu> Launchpad bug 122258 in bzr "http decorators incorrectly handled when authentication is used" [Low,Confirmed]  https://launchpad.net/bugs/122258
[09:24] <vila> ubotu: thanks
[09:24] <ubotu> You're welcome! But keep in mind I'm just a bot ;-)
[09:24] <poolie_> haha
[09:25] <poolie_> i'm going to put my head down into this for another hour or so, anything else to talk about?
[09:25] <igc> vila - get my reply?
[09:25] <poolie_> if not, have a good weekend
[09:25] <vila> igc: no
[09:25] <vila> poolie_: have a good weekend too
[09:25] <igc> no - that's all poolie - thanks
[09:25] <poolie_> thanks
[09:26] <igc> vila - yes, it means you bring good luck
[09:26] <vila> igc: kthks
[09:26] <igc> (when I reply in Gaim, people don't see my replies)
[09:26] <igc> (promises himself to get to the bottom of that one day soon)
[09:26] <vila> igc: :)
[10:10] <ubotu> New bug: #141438 in bzr "BundleTester.test_unicode_bundle fails for WorkingTree3 on OSX" [Low,Triaged]  https://launchpad.net/bugs/141438
[10:28] <igc> have a good weekend all
[10:34] <poolie_> night
[11:28] <matkor> Is it possible to update remote checkout ?  bzr update sftp://host/bzr-dir ? I get (bzr: ERROR: sftp://www-cz.ant.vpn/usr/lib/python2.4/site-packages/abbon2/.bzr/ is not a local path) ?
[11:30] <spiv> matkor: Not builtin.  There's "ssh host bzr bzr-dir".
[11:30] <ubotu> New bug: #141456 in bzr "merging of branches with nested trees fails when commiting" [Undecided,New]  https://launchpad.net/bugs/141456
[11:30] <spiv> Er, "ssh host bzr update bzr-dir"
[11:30] <spiv> There's a plugin that automates that: https://launchpad.net/bzr-push-and-update/
[11:31] <matkor> spiv: Yeah but when checkout on host is from remote repo-host I would have to give access to repo-host to host which is not always good idea ...
[11:31] <matkor> give access = give key / password to ssh executed on host
[11:34] <matkor> I would be nice to have keys on trusted-host give them to host and repo-host and than on trusted-host be able to bzr update host ...
[11:35] <sabdfl> howdy revisionistas
[11:59] <AnMaster> I have to pull from a lot of branches with long names, is there anyway to store a shorthand so I can use bzr pull someword for http://foo.bar.com/~user/long/url
[12:00] <AnMaster> using --remember doesn't work well when you pull from several
[12:22] <hdh> I create a bzr repo in my firefox profile dir, and it crashed with this http://pastebin.ca/705679
[12:33] <spiv> hdh: hmm, that's because there's a backslash in the filename
[12:33] <spiv> It shouldn't traceback about that though.
[12:34] <GaryvdM> AnMaster: You could use enviroment vars.
[12:34] <AnMaster> GaryvdM, hm :(
[12:34] <spiv> hdh: it's this bug https://bugs.launchpad.net/bzr/+bug/81844
[12:34] <ubotu> Launchpad bug 81844 in bzr-svn "Handle backslashes in filenames more gracefully" [Low,Invalid] 
[12:34] <AnMaster> GaryvdM, any better idea?
[12:35] <hdh> spiv: thanks, I should have thought of lp before
[12:36] <GaryvdM> Sorry - no
[12:42] <uws> AnMaster, GaryvdM: what I do is this. I create a local repository and mirror all upstream branches I pull from locally (doesn't take much space because of the shared repository) into local directories with a convenient name, e.g. repodir/some-project.person-name. Then I just pull/merge into my own branch using  "bzr pull ../some-project.some-other-person"
[12:43] <AnMaster> uws, interesting
[12:43] <uws> AnMaster, GaryvdM: (note that each mirror remembers the upstream url, so it fixes the problem)
[12:43] <AnMaster> but well not perfect
[12:43] <AnMaster> best would be aliased such
[12:44] <AnMaster> I don't know how to make a feature request, but I'm requesting this feature
[12:44] <AnMaster> so if someone want to make a feature request: thanks
[12:46] <GaryvdM> AnMaster: you can make a feature request as a bug here: https://bugs.launchpad.net/bzr/+filebug
[12:46] <AnMaster> need some login?
[12:46] <AnMaster> :/
[12:46] <AnMaster> oh well
[12:46] <AnMaster> will to that after I get some food
[12:54] <GaryvdM> I need to test if some code I have written works with branchs that have ghosts. How do you create a branch that has ghosts?
[01:00] <GaryvdM> Ok - bzr.dev has ghosts - so I'll just use that...
[01:36] <ubotu> New bug: #141478 in bzr "`bzr status -rN..M` in branch w/o tree produce NoWorkingTree error" [Undecided,New]  https://launchpad.net/bugs/141478
[02:00] <vila> mrevell: ping
[02:00] <mrevell> hi vila
[02:01] <vila> hi mathew, I can't push to launchpad anymore, seems something broke in the last minutes or so, you're aware of it ?
[02:01] <elmo> bazaar.launchpad.net and codebrowse.launchpad.net are down for emergency maintenance, ETD is 10 minutes
[02:02] <elmo> [sorry, forgot to announce that in this channel] 
[02:02] <mrevell> thanks elmo
[02:02] <vila> elmo: thanks
[02:02] <vila> elmo: I mean, thanks for telling us and doing the maintenance too :)
[02:03] <mrevell> vila: I've just added a comment in response to your comment on the documentation audit bu
[02:03] <mrevell> s/bu/bug
[02:04] <vila> to tell the whole story I tried to push from a wrong machine, get a ssh request about a new IP address, get bounced because the machine was not authorized, went to the right machine, get an unreachable host and wondered if I had broken something :-)
[02:04] <elmo> should be back now
[02:05] <vila> elmo: wow, slow down, I still have to answer mrevell :)
[02:06] <vila> mrevell: Great news !!!!
[02:07] <vila> mrevell: from the outside, canonical looks a bit like Santa Klaus or the Tooth Fairy: surprises pop up unexpected  :)
[02:13] <vila> elmo: I pushed without problems (just to confirm it's back and ok from my side)
[04:27] <fbond> Hey, anyone know of any recent RPMs (or SRPMs) that I can use on my company's RHEL4 (ugh) system?
[05:07] <vila> fbond: look at http://bazaar-vcs.org/Download
[05:08] <vila> if you can't use an rpm package, installing from source is not *that* hard, you need python2.4 though (python -V)
[05:10] <fbond> vila: thanks, I did look there.  I will see what I can do.  I don't like installing things from source due to maintenance headaches.
[05:11] <fbond> I'm more likely to build my own rpms.
[05:11] <vila> fbond: that's why you should pester your admins to update to a newer RHEL :)
[05:12] <fbond> Well ... I am the admin, but we are on a managed server that I don't have physical access to, and my plates already full because we're a bit understaffed for that sort of thing.
[05:12] <vila> fbond: if you build a usable RPM we will gladly add it to the wiki (come back here for how)
[05:12] <fbond> vila: okay, I'll keep you up to date
[05:13] <vila> I'm not the one to contact for that, but Those Who Can read the logs :)
[05:14] <vila> fbond: and thanks in advance
[05:46] <vila> :-( Got a corrupt repo (first time ever though), any advice about what I should backup for diagnosis: .bzr.tgz, .bzrlog, anything else ?
[05:47] <vila> backtrace ends with: KnitCorrupt: Knit <bzrlib.knit._KnitAccess object at 0xb776e4cc> corrupt: While reading {v.ladeuil+lp@free.fr-20070921114314-1tro2mobuor8e8zh} got IOError(Not a gzipped file)
[05:48] <vila> and revisions.knit contains zeroes (0x00) on the whole range described in revisions.kndx...
[05:53] <lapthrick> hey
[05:54] <lapthrick> jelmer: why is bzr-svn still marked alpha on the plugins page?
[05:55] <ubotu> New bug: #141538 in bzr-eclipse "cannot bzr init" [Undecided,New]  https://launchpad.net/bugs/141538
[05:57] <lapthrick> jelmer: also, copy + delete => rename is listed as TODO, yet you have a screenshot demonstrating that it works :)
[05:59] <GaryvdM> lapthrick: if you rename in bzr, then push to svn, and then pull to bzr - it knows it was a rename
[05:59] <GaryvdM> if you rename in svn, then pull to bzr - it shows as a copy + delete
[05:59] <lapthrick> GaryvdM: I mean http://samba.org/~jelmer/bzr/bzrsvn-renames.png
[06:01] <GaryvdM> Hmm - he was saying last night that it does not do that.
[06:01] <lapthrick> hmm, plugins page link to http://people.samba.org/bzr/jelmer/bzr-svn/0.3/
[06:01] <phanatic> GaryvdM: your vizchanges branch looks good. it feels much faster, and i like the new curly graphs ;)
[06:01] <GaryvdM> Best to wait for him
[06:01] <lapthrick> shouldn't it be 0.4/ ?
[06:01] <GaryvdM> Thanks phanatic
[06:01] <lapthrick> phanatic: screenshot!
[06:02] <lapthrick> and what are the rules bzr follows if a plugin is installed both system-wide and in ~ ?
[06:02] <phanatic> lapthrick: the branch is still hot ;)
[06:02] <lapthrick> phanatic: that doesn't impair your screenshotting ability, does it? :)
[06:03] <GaryvdM> I'll upload one now
[06:03] <GaryvdM> Branch is here: https://code.launchpad.net/~garyvdm/bzr-gtk/vizchanges
[06:04] <phanatic> lapthrick: it's not about screenshooting ability, but laziness :P
[06:05] <lapthrick> bzr needs checkout --light aliased to `cl'
[06:06] <Odd_Bloke> lapthrick: You can add aliases yourself...
[06:06] <GaryvdM> lapthrick: http://garyvdm.googlepages.com/bzr-gtk-vizchanges.png
[06:07] <lapthrick> how can I quote a particular comment in launchpad?
[06:07] <lapthrick> Odd_Bloke: oh?
[06:10] <Odd_Bloke> lapthrick: http://doc.bazaar-vcs.org/bzr-0.15/using_aliases.htm
[06:10] <Odd_Bloke> That's reasonably old but the method should stand.
[06:11] <lapthrick> nifty, thanks
[06:46] <hsn_> is there plugin for netbeans ide?
[07:10] <james_w> Can anybody think of a fix for the following issue. I have a plugin that I am trying to run the testsuite of during the package build.
[07:10] <james_w> it does this by running python __init__.py which sets up a test runner with the test suite.
[07:11] <james_w> one of the tests then does from bzrlib.plugins import builddeb, as it needs to test something defined in the __init__.py.
[07:11] <james_w> This fails as the plugin is not registered, and so it can't be imported that way.
[07:12] <james_w> I can't set BZR_PLUGIN_PATH I don't think, as the code builds in a directory with a '-' in it, which bzr rejects.
[07:12] <james_w> I see a few options:
[07:12] <james_w> 1. copy all the code in to a new directory for the test, and then set BZR_PLUGIN_PATH.
[07:13] <james_w> 2. move the thing that needs to be tested in to another module, and then simply import it in to __init__.py.
[07:13] <james_w> 3. register the plugin before the tests are run.
[07:13] <james_w> does anyone have an opinion about which is the least ugly?
[07:33] <carlesoriol> hi. I'm carles Oriol from the catalan LoCo and I was thinking about create a bazaar for all the documentation and designs (logos, formats) of our LoCo. Is it possible? or it's too much  for the bazaar?
[07:34] <carlesoriol> (bazaar project)
[07:34] <james_w> how much are you talking about?
[07:34] <carlesoriol> 300 Mb at the moment
[07:35] <james_w> what's the largest file?
[07:35] <carlesoriol> around 10 Mb
[07:36] <james_w> that should be ok.
[07:36] <carlesoriol> james_w: ok. Thanks for all
[07:36] <james_w> however branching over the network will be slow at the moment.
[07:36] <james_w> that should hopefully be a lot better next release (about a month).
[07:37] <carlesoriol> james_w: well... If it's not a problem i'll organize the structure and then i can wait
[07:44] <james_w> Lo-lan-do: thanks for bzr+ssh:// on alioth (I assume you had something to do with it).
[07:45] <dato> it was buxy, actually, ages ago
[07:45] <james_w> hi dato.
[07:45] <dato> hey james_w
[07:45] <james_w> I've just fixed builddeb for that problem you were having trying to build it.
[07:46] <dato> I saw
[07:47] <Lo-lan-do> james_w: Maybe, maybe not.  Forgot :-)
[07:47] <james_w> Lo-lan-do: have you considered setting up shared repositories for each project?
[07:51] <Lo-lan-do> I think we basically only provide a directory, and everyone is free to use it as they wish.
[07:52] <Lo-lan-do> That includes creating repositories.
[07:52] <james_w> providing repositories should transparently improve performance (including less server bandwidth).
[07:54] <dato> not less server outgoing bandwidth
[07:54] <Lo-lan-do> Yeah, but I guess some projects may have unrelated branches
[07:54] <dato> or most, one per package
[07:59] <Lo-lan-do> I'll add the recommendation to the wiki page
[08:01] <james_w> dato: all done I think. Could you try again on your next upload round please?
[08:02] <dato> james_w: ok
[08:02] <james_w> thanks.
[08:03] <james_w> jam's back.
[08:08] <Lo-lan-do> Can one initialize a repository distantly?
[08:09] <james_w> In theory yes.
[08:09] <dato> yes
[08:10] <dato> just try it :)
[08:10] <james_w> and in practice.
[08:13] <Lo-lan-do> http://wiki.debian.org/AliothBzr updated
[08:18] <james_w> thanks Lo-lan-do
[09:22] <vila> let's say I have identified a corrupted revision in ./bzr/repository/revisions.knit
[09:23] <vila> Am I right in supposing that if I delete the corresponding line in revision.kndx, I will be safe ?
[09:24] <vila> Or should I also delete it in all .kndx in the knits hierarchy ?
[09:25] <vila> s#knits#repository/knits#
[09:25] <vila> Of course it's a shared repository
[09:25] <vila> abentley: ^ ?
[09:28] <vila> lifeless: ^ ?
[09:31] <vila> Did I mentioned that bzr check gives a traceback ?
[09:35] <vila> ubotu: ^ ?