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