[00:01] <dev001> Anyone here use the QBzr eclipse plugin?  Using the recommended (http://wiki.bazaar.canonical.com/QBzrEclipse) update site, http://bazaar.canonical.com/releases/3rd-party/qbzr-eclipse, returns a "repository not available" in Eclipse.
[13:58] <Noldorin> i see the following in my bzr log:
[13:58] <Noldorin> WARNING: "Key 'tfs+http://' already registered"
[13:58] <Noldorin> where do protocols actually get registered?
[14:01] <jelmer> Noldorin, they get registered when a plugin is loaded
[14:02] <jelmer> Noldorin, I've seen that particular error a couple of times when a plugin had syntax errors and was installed in two locations (system and user home)
[14:02] <Noldorin> jelmer, ah right
[14:02] <Noldorin> jelmer, problem is, the plugin is installed *nowhere* on my system
[14:02] <Noldorin> not that i can find
[14:02] <Noldorin> yet it's still picking it up somehow
[14:03] <jelmer> Noldorin, it would be..
[14:03] <Noldorin> ?
[14:04] <jelmer> Noldorin: this error suggests it's still installed *somewhere*
[14:04] <Noldorin> ok
[14:04] <Noldorin> i've checked all the usual places though
[14:04] <Noldorin> jelmer, anywhere you'd suggest to look now?
[14:05] <jelmer> Noldorin, have you checked /usr/local ?
[14:05] <Noldorin> jelmer, Windows. but yes, the equivalent
[14:14] <Noldorin> jelmer, ok, very strange. it wasn't showing in Windows Explorer, but another utility picked it up
[14:14] <Noldorin> oh well
[14:14] <Noldorin> bbl
[14:34] <vila> Noldorin: ha, finally, the ghost get out of its hole... Tell us what you find as it may happen to someone else and I'd really like to understand what happened to you.
[16:22] <knittl> how can i do a log on a file which was moved in an earlier revision?
[16:22] <knittl> bzr log -- $filename does not work
[16:22] <knittl> :-/
[16:55] <mgz> vila: this is the runtime problem with your leaks branch:
[16:55] <mgz> http://float.endofinternet.org/temp/leaking_diff.xml#bt.test_remote.TestRemoteRepositoryCopyContent.test_copy_content_remote_to_local
[16:56] <mgz> done a great job of squashing leaks, but a fraction of them have turned from 100ms leaks to 5000ms hang timeouts
[16:57] <mgz> and some are even worse:
[16:57] <mgz> http://float.endofinternet.org/temp/leaking_diff.xml#bb.test_branch
[16:58] <mgz> I'll poke around all that orange now.
[17:28] <mgz> okay, don't completely understand that orange, but the fix is easy
[17:28] <mgz> don't store the real get_transport method on the test instance and close over self, just close over the real method
[17:29] <jelmer> hi mgz
[17:29] <mgz> hey jelmer.
[17:40] <Noldorin> vila, back. i certainly will. it's baffled me too!
[17:43] <Noldorin> vila, you there?
[17:45] <mgz> he's probably having a nice non-work sunday afternoon now :)
[17:45] <Noldorin> heh, probably.
[17:46] <Noldorin> so was i, but this bzr stuff is haunting me :)
[18:38] <vila> mgz: ha, yeah, sure, I know about them but I decided to ignore them for the time being. It should be possible to reduce the timeout though, I just haven't experimented with that
[18:39] <mgz> yeah, we did discuss them before, just didn't time the full test run previously
[18:39] <vila> mgz: I have still to see why you need to *avoid* the closures instead of breaking the cycles. 'closures' are too powerful to get rid of them unless there is really no other solution IMNSHO
[18:40] <mgz> quite often the cycle is accidental and redundant anyway - for instance, the change to get rid of that orange actually makes the code simpler
[18:40] <vila> Noldorin, mgz: It's raining here. But not in movie theaters. 'Inception' is... one of my favourites from now on :0)
[18:41] <mgz> I'm off to cinema in an hour or so too.:)
[18:41] <vila> mgz: also, keep in mind that the get_transport trick is temporary, a better solution will be a hook.
[18:42] <vila> mgz: hehe, movie already chosen ?
[18:42] <mgz> scott pilgrim. which I have no idea whether I'll like or not, but hey.
[18:43] <vila> mgz: hmm, let us know ;-)
[18:44] <vila> Noldorin: I won't stay long, it's dinner time for me
[19:50] <Noldorin> vila, sorry, had to disappear
[19:50] <Noldorin> anyway, seems the main problem was that the file was deleted from the directory index but was still on disk :S
[19:50] <Noldorin> or something like such
[19:50] <Noldorin> since windows explorer wasn't listing it
[19:51] <vila> Noldorin: even with a refresh (F5) ?
[19:51] <Noldorin> yes
[19:52] <vila> weird :(
[19:52] <Noldorin> vila, yes, it's strange. i think bzr/python is doing something strange (non-windows like) to list the plugins directory
[19:53] <Noldorin> vila, at least you know for future reference though :)
[19:53] <vila> bzr/python relies on the file system, if something is strange, it's there
[19:54] <vila> that, or windows explorer...
[19:54] <Noldorin> vila, yeah, maybe it' just doing something "non-windows-like"
[19:54] <Noldorin> oh well
[19:54] <Noldorin> still curious how i can get bzr-tfs set up on windows hmm
[19:55] <vila> Noldorin: sry, I haven't look into this plugin, yet
[19:56] <Noldorin> that's fine
[19:56] <jelmer> Noldorin: are the codeplex repositories available using tfs?
[19:56] <Noldorin> jelmer, absolutely. it's the 'primary' VCS for codeplex
[19:56] <jelmer> ah, cool
[19:58]  * jelmer updates the error message in codeplex to mention bzr-tfs
[20:01] <mgz> jelmer: it's my understanding that the xml stuff dead code on modern formats as well, but want someone who actually knows to say that.
[20:01] <jelmer> mgz: In that case, consider it said :-)
[20:02] <mgz> okay, time for one more bug before I leave
[20:02] <Noldorin> bzr push tfs+https://tfs.codeplex.com/ircdotnet/devel
[20:02] <Noldorin> jelmer, i am trying that but no luck
[20:02] <Noldorin> bzr: ERROR: exceptions.ValueError: need more than 1 value to unpack
[20:02] <vila> mgz: consider it repeated :)
[20:06] <Noldorin> ah, seems my url format is bad
[20:35] <FryGuy-> i had a bunch of problems getting bzr-tfs to work on our tfs 2010 server :(
[20:37] <mgz> okay cinema tomorrow evening instead
[20:39] <lifeless> mgz: enjoy
[20:42] <mgz> left it too late for tonight (and the weather is kinda horrid even for driving into town)
[20:44] <mgz> lifeless: I've got some changes for pyjunitxml, do you want mps?
[20:44] <lifeless> please
[20:44] <mgz> also, aren't expectedfailure and unexpectedsuccess backwards?
[20:44] <mgz> they get treated like a failure and a success respectively.
[20:47] <lifeless> good catch
[20:48] <mgz> I'll switch them, and use... unittest.case._UnexpectedSuccess for the exception name?
[20:49] <lifeless> thats not very backwards compatible
[20:49] <lifeless> if its from testtools its ok
[20:49] <lifeless> (I think; does pyjunitxml use testtools already?)
[20:49] <mgz> nope.
[20:49] <lifeless> hmm, or is that just a string literal
[20:49] <lifeless> if its just a string literal thats ok with me.
[20:49] <mgz> right, string just for the xml attribute content
[20:50] <lifeless> its been a while since I opened that project ;)
[20:50] <mgz> :)
[20:58] <lifeless> mgz: btw, the monkey patching xml stuff
[20:58] <lifeless> mgz: -huge- performance win
[20:59] <mgz> I can imagine, but is it still used?
[20:59] <lifeless> as jam says, in bundles
[20:59] <lifeless> I'm neutral on removing the optimisation
[20:59] <lifeless> let me say that
[20:59] <mgz> ah, not looked at mail again yet
[20:59] <lifeless> me, I closed the thread
[20:59] <lifeless> anyhow, I'm on the fence
[20:59] <lifeless> some folk still have older format branches
[21:00] <lifeless> dunno what %; LP probably knows
[21:00] <mgz> hm, wonder if junit will fall over if a failure element has no content...
[21:05] <mgz> I can live with updating the hack, just didn't know how important it was and didn't get an answer on the bug, so figured sticking an mp up was a way to get people who cared to speak up
[21:10] <lifeless> fair 'nuff
[21:14] <lifeless> mgz: does my comment about LBYL make sense to you?
[21:14] <lifeless> was possibly a bit opaque
[21:37] <mgz> lifeless: it does, two thoughts on it,
[21:38] <mgz> one, I'm not sure on the ideas of what is allowed to raise BzrCommandError so sticking it underneath a similar one for subunit absense seemed safe
[21:38] <lifeless> you can raise a non BzrCommandError
[21:39] <Noldorin> FryGuy-, yeah, seems bzr-tfs doesn't like the codeplex servers either
[21:39] <lifeless> as long as internal=False, it will format the same
[21:39] <mgz> also, wanted to always raise it, not silently let it pass if concurrency=1
[21:39] <Noldorin> FryGuy-, from what i've seen...
[21:39] <FryGuy-> i made a bunch of hacks on mine to get it to work
[21:39] <FryGuy-> but then it stopped working
[21:39] <lifeless> mgz: that last bit isn't particularly compelling to me; I'm curious why it is to you ?
[21:39] <mgz> but could move to bzrlib.tests.fork_decorator instead, which is a bit closer to the actual site
[21:40] <lifeless> yes, that would be better
[21:40] <FryGuy-> noldrin: do you want to try my version and see if it's any better?
[21:40] <lifeless> the main point for me is that this is delegated reponsibility
[21:40] <mgz> because I'm on a 1 cpu machine and was very confused the other day when trying to repo --parallel things
[21:41] <lifeless> is there an optimisation to not fork if cpu count = 1? that would be a bug unless its in fork_decorator (because ec2 *has* to go to ec2 :P)
[21:41] <mgz> there is, both the --parallel decorators do nothing if 1
[21:49] <lifeless> mgz: there are three :)
[21:50] <mgz> hiding!
[21:51] <fullermd> Pah.  If it were REALLY parallel, it would create an arbitrary number of decorators on demand...
[21:52] <lifeless> mgz: the third is in a plugin
[21:52] <lifeless> mgz: bzr-ec2test
[21:53] <mgz> hm, I just hit 's' rather than 'e' in feed-pqm by mistake
[21:53] <mgz> will that do bad things?
[21:53] <lifeless> it will use the API
[21:53] <lifeless> which pqm is not looking at now
[21:54] <mgz> what letter do I use for "disregard that, I'm an idiot"?
[21:54] <lifeless> e
[21:55] <mgz> but it's not in the list any more...
[21:56] <lifeless> run with --show-queued or whatever the option is
[21:56] <mgz> ah, ta.
[22:18] <mgz> ark, now I understand why running the pyjunitxml test suite doesn't work on python 2.4
[22:19] <mgz> it's the __main__  vs. unittest thing
[22:20] <mgz> get two different sets of classes so unittest.TestSuite instance is not a __main__.TestSuite
[22:20] <mgz> what's the normal hack around that?
[22:21] <lifeless> use python 2.5 ?
[22:21] <lifeless> boom-tish
[22:21] <mgz> also fails on 2.5
[22:21] <lifeless> uhm, sigh
[22:21] <lifeless> I forget
[22:21] <mgz> so, presume you need 2.6 at least.
[22:22] <lifeless> does python -m subunit.run pyjunitxml.test_suite work ?
[22:23] <mgz> that's a package, not a module, so not for my 2.4 no
[22:24] <lifeless> python /path/to/subunit/run.py pyjunitxml.test_suite
[22:24] <mgz> I think I tried using the testtools runner script directly the other day and that didn't work for some other reason
[22:56] <mgz> okay, nearly at the bug that actually started me on this crusade now...