[00:12] hi folks - can bzr-svn import a subversion repository? [00:12] yes [00:15] lifeless: i used the command bzr svn-import (url) and got the error (url) appears to contain a branch. For individual branches, use 'bzr branch' - help [00:19] anyone? [00:20] sorry, got stuff happening here [00:20] have you read the user docs on migration? they are pretty good I think [00:22] lifeless: no - they are woeful [00:45] billy: did the url have /trunk/ or something at the end? [00:45] james_w: yes [00:45] then remove that part [00:46] james_w: trying now [00:49] james_w: while i'm waiting the error said use 'bzr branch' so would 'bzr svn-import branch' be a valid command? [00:55] billy: No. It works like this: 'bzr branch svn-url' to import a single branch, or 'bzr svn-import svn-url' to import all branches below a directory [00:56] maxb: thanks === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [11:14] hey, i'm havign troubles branching any lp: link, any ideas what might be the reason [11:14] ? [11:14] without a description of what happened, no [11:15] lifeless: not sure. didn't do anything special. any lp:something i'm trying to branch give me an error for no existence [11:16] bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~ [11:16] what happens if you try bzr branch lp:python-fixtures [11:19] bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~python-fixtures/python-fixtures/trunk/". [11:19] ok [11:19] can you ssh to bazaar.launchpad.net successfully ? [11:19] trying [11:19] it should tell you that no shells are permitted [11:20] seems so [11:20] this is very odd [11:20] its also very late for me [11:20] wait.. not sure [11:20] sec [11:20] can you please file a question on https://answers.launchpad.net/launchpad-code/ [11:22] i had conf problem with ssh. trying now again [11:23] okay, i found what was the problem. it was ssh configuration problem [11:24] cool [11:24] lifeless: many thanks [11:24] np [15:01] if two people are working on a project and one wants to use git and the other bzr, is it reasonable to use svn on the server as a sort of go between? Or will that cause issues in the long run? And if so has anyone experience with git and bzr working together? [15:03] Pilky: that should work [15:04] and I assume merging can be done locally so git and bzr manage it, rather than having to fight with svn? [15:11] Pilky: bzr can, I'm not sure about git [15:11] ok, thanks [15:11] we may still end up using one or the other, I just don't want to force this other guy into using bzr but I really do not want to have to deal with git :p [15:16] :-) [17:17] wow, I thought pyjunitxml was flakey, but bzr-xmloutput makes it look like something designed to run fighter planes [17:17] sure, python doesn't actually make it easy to do xml The Right Way, but there are alternatives to print-and-hope [17:17] mgz, in what way is bzr-xmloutput flakey? [17:18] it's not very careful in ensuring what it's creating is actually well-formed [17:20] I think I will not worry about that right now and just fix the import like I was going to. [17:22] ...aren't plugins meant to import their bits from bzrlib.plugins rather than the root namespace? [17:41] mgz: yes [17:47] ugh, I'm failing to see a way to fix this without fixing one of several larger problems [18:05] mgz: What are you trying to do with bzr-xmloutput? [18:51] jelmer: https://bugs.launchpad.net/bzr/+bug/614522 <- comment #2 [18:51] Launchpad bug 614522 in Bazaar "Monkey patching private escaping functions breaks with ElementTree 1.3 (affected: 1, heat: 6)" [High,Fix released] [18:52] ah, hmm [18:54] I think the shortest path for me is fixing all the weird import/lazy import stuff first, then just taking the function from elementtree as I suggest [18:54] +ed [18:54] means I don't need to worry about the (lack of) correctness over the actual xml generation [19:14] okay, I now kinda wish I hadn't fixed that Python 2.5ism in the test suite, I did not want to see the result... [19:14] Ran 83 tests in 15.609s [19:14] FAILED (failures=10, errors=48) [19:33] mgz, whoa [19:34] I good number are from a bug I noticed earlier and nearly commented on in here [19:35] there's this copy-coded all over the place: [19:35] self.outf.write('' % \ [19:35] bzrlib.osutils.get_user_encoding()) [19:35] vs. [19:35] "t is RECOMMENDED that character encodings registered (as charsets) with the Internet Assigned Numbers Authority [IANA-CHARSETS], other than those just listed, be referred to using their registered names; other encodings SHOULD use names starting with an "x-" prefix." [19:35] expat doesn't like all the encoding names the python encoding module knows about [19:48] there's also some weirdness with an extra args element for errors, probably python 2.4 related: [19:48] http://float.endofinternet.org/xmlbin/2.2_bp.xmloutput#bp.xmloutput.tests.test_info_xml.TestInfoXml.test_info_non_existing [20:49] mgz: hi [20:49] hey lifeless. [20:50] I'm looking at a similar sort of thing [20:50] intern() in 2.5 is blowing up (thing is unicode), and not in 2.6, and I can't tell if its: [20:50] - internt [20:50] - writlines [20:50] - stringio [20:50] blah [20:51] intern needs str objects on 2.4 at least. [20:52] yeah [20:52] it does on 2.6 too [20:52] so stringio or writelines or *something* is casting. [20:52] * lifeless hates on autocasting some more [20:53] cStringIO should be safe (doesn't like unicode at all), but StringIO will autocast [20:53] writelines... depends on the file-like [20:55] yeah [20:55] this is 2.5 breaks, 2.6 works [20:56] 2.5 is of course only accessible in an ec2 instance. [20:59] anything I can run for you, or does this mission start by branching launchpad? (which I've still never succeeded at) [20:59] the latter [20:59] its test isolation, which makes me even happier [21:03] okay, getting somewhere, import fixing and hacks got me down to FAILED (failures=17, errors=10), and if I could work out IllegalUseOfScopeReplacer weirdness I'd be even happier [21:04] ok [21:04] so that one can be fun [21:04] calling gc.collect() can cause it [21:05] IIRC, alternatively it was using gc.objects can trigger it [21:05] either of those being done? [21:06] as far as I can see, no, but this is in blackbox-style testing so there's a *lot* going on. it may just be circualr import weirdness, I've not finished cleaning all this up yet. [21:08] I was beating me head on the wall on friday with something similar [21:08] the tests for much of launchpad go via the entire stack [21:08] skipping only http wire protocol [21:09] so this includes a thing called the 'publisher' whose job it is is to make sure no information about internals escapes to the web client [21:09] ... can you see the problem :P [21:10] there's a place for end-to-end testing, just... not everywhere please ;_; [21:19] Of course not. Only at the ends 8-} === Leonidas_ is now known as Leonidas [22:04] okay, this is so far from where I started, but the lazy_import thing is starting to make sense [22:05] for some reason, the find-tests-in-plugin code is both triggering the lazy import load (understandable, probably just touches every object in scope), and cleans it up (why?) before any test ever runs [22:16] ...okay, this is funny, and stupid. [22:37] okay, fixed, and I'm going to poke bzrlib so no one else gets into that kind of tiz again [22:38] summary, "from thispackage import module" is a bad idea [22:39] mgz: we use that a lot, I think that's the recommended way of importing modules [22:40] lazy import lets you do it, but module is a lazy object, that when it tries to resolve the import... finds *itself* in the package __dict__ and doesn't actually import anything [22:41] you just get a lazy object containing... itself... that then goes away [22:41] I hadn't really thought through what the code I'd written was doing...