[00:12] <billy> hi folks - can bzr-svn import a subversion repository?
[00:12] <lifeless> yes
[00:15] <billy> 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] <billy> anyone?
[00:20] <lifeless> sorry, got stuff happening here
[00:20] <lifeless> have you read the user docs on migration? they are pretty good I think
[00:22] <billy> lifeless: no - they are woeful
[00:45] <james_w> billy: did the url have /trunk/ or something at the end?
[00:45] <billy> james_w: yes
[00:45] <james_w> then remove that part
[00:46] <billy> james_w: trying now
[00:49] <billy> james_w: while i'm waiting the error said use 'bzr branch' so would 'bzr svn-import branch' be a valid command?
[00:55] <maxb> 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] <billy> maxb: thanks
[11:14] <Ddorda> hey, i'm havign troubles branching any lp: link, any ideas what might be the reason
[11:14] <Ddorda> ?
[11:14] <lifeless> without a description of what happened, no
[11:15] <Ddorda> 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] <Ddorda> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~
[11:16] <lifeless> what happens if you try bzr branch lp:python-fixtures
[11:19] <Ddorda> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~python-fixtures/python-fixtures/trunk/".
[11:19] <lifeless> ok
[11:19] <lifeless> can you ssh to bazaar.launchpad.net successfully ?
[11:19] <Ddorda> trying
[11:19] <lifeless> it should tell you that no shells are permitted
[11:20] <Ddorda> seems so
[11:20] <lifeless> this is very odd
[11:20] <lifeless> its also very late for me
[11:20] <Ddorda> wait.. not sure
[11:20] <Ddorda> sec
[11:20] <lifeless> can you please file a question on https://answers.launchpad.net/launchpad-code/
[11:22] <Ddorda> i had conf problem with ssh. trying now again
[11:23] <Ddorda> okay, i found what was the problem. it was ssh configuration problem
[11:24] <lifeless> cool
[11:24] <Ddorda> lifeless: many thanks
[11:24] <lifeless> np
[15:01] <Pilky> 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] <jelmer> Pilky: that should work
[15:04] <Pilky> and I assume merging can be done locally so git and bzr manage it, rather than having to fight with svn?
[15:11] <jelmer> Pilky: bzr can, I'm not sure about git
[15:11] <Pilky> ok, thanks
[15:11] <Pilky> 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] <jelmer> :-)
[17:17] <mgz> wow, I thought pyjunitxml was flakey, but bzr-xmloutput makes it look like something designed to run fighter planes
[17:17] <mgz> sure, python doesn't actually make it easy to do xml The Right Way, but there are alternatives to print-and-hope
[17:17] <jelmer> mgz, in what way is bzr-xmloutput flakey?
[17:18] <mgz> it's not very careful in ensuring what it's creating is actually well-formed
[17:20] <mgz> I think I will not worry about that right now and just fix the import like I was going to.
[17:22] <mgz> ...aren't plugins meant to import their bits from bzrlib.plugins rather than the root namespace?
[17:41] <jelmer> mgz: yes
[17:47] <mgz> ugh, I'm failing to see a way to fix this without fixing one of several larger problems
[18:05] <jelmer> mgz: What are you trying to do with bzr-xmloutput?
[18:51] <mgz> jelmer: https://bugs.launchpad.net/bzr/+bug/614522 <- comment #2
[18:52] <jelmer> ah, hmm
[18:54] <mgz> 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] <mgz> +ed
[18:54] <mgz> means I don't need to worry about the (lack of) correctness over the actual xml generation
[19:14] <mgz> 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] <mgz> Ran 83 tests in 15.609s
[19:14] <mgz> FAILED (failures=10, errors=48)
[19:33] <jelmer> mgz, whoa
[19:34] <mgz> I good number are from a bug I noticed earlier and nearly commented on in here
[19:35] <mgz> there's this copy-coded all over the place:
[19:35] <mgz> self.outf.write('<?xml version="1.0" encoding="%s"?>' % \
[19:35] <mgz>         bzrlib.osutils.get_user_encoding())
[19:35] <mgz> vs.
[19:35] <mgz> "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] <mgz> expat doesn't like all the encoding names the python encoding module knows about
[19:48] <mgz> there's also some weirdness with an extra args element for errors, probably python 2.4 related:
[19:48] <mgz> http://float.endofinternet.org/xmlbin/2.2_bp.xmloutput#bp.xmloutput.tests.test_info_xml.TestInfoXml.test_info_non_existing
[20:49] <lifeless> mgz: hi
[20:49] <mgz> hey lifeless.
[20:50] <lifeless> I'm looking at a similar sort of thing
[20:50] <lifeless> intern() in 2.5 is blowing up (thing is unicode), and not in 2.6, and I can't tell if its:
[20:50] <lifeless>  - internt
[20:50] <lifeless>  - writlines
[20:50] <lifeless>  - stringio
[20:50] <lifeless> blah
[20:51] <mgz> intern needs str objects on 2.4 at least.
[20:52] <lifeless> yeah
[20:52] <lifeless> it does on 2.6 too
[20:52] <lifeless> so stringio or writelines or *something* is casting.
[20:52]  * lifeless hates on autocasting some more
[20:53] <mgz> cStringIO should be safe (doesn't like unicode at all), but StringIO will autocast
[20:53] <mgz> writelines... depends on the file-like
[20:55] <lifeless> yeah
[20:55] <lifeless> this is 2.5 breaks, 2.6 works
[20:56] <lifeless> 2.5 is of course only accessible in an ec2 instance.
[20:59] <mgz> anything I can run for you, or does this mission start by branching launchpad? (which I've still never succeeded at)
[20:59] <lifeless> the latter
[20:59] <lifeless> its test isolation, which makes me even happier
[21:03] <mgz> 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] <lifeless> ok
[21:04] <lifeless> so that one can be fun
[21:04] <lifeless> calling gc.collect() can cause it
[21:05] <lifeless> IIRC, alternatively it was using gc.objects can trigger it
[21:05] <lifeless> either of those being done?
[21:06] <mgz> 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] <lifeless> I was beating me head on the wall on friday with something similar
[21:08] <lifeless> the tests for much of launchpad go via the entire stack
[21:08] <lifeless> skipping only http wire protocol
[21:09] <lifeless> 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] <lifeless> ... can you see the problem :P
[21:10] <mgz> there's a place for end-to-end testing, just... not everywhere please ;_;
[21:19] <fullermd> Of course not.  Only at the ends   8-}
[22:04] <mgz> okay, this is so far from where I started, but the lazy_import thing is starting to make sense
[22:05] <mgz> 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] <mgz> ...okay, this is funny, and stupid.
[22:37] <mgz> okay, fixed, and I'm going to poke bzrlib so no one else gets into that kind of tiz again
[22:38] <mgz> summary, "from thispackage import module" is a bad idea
[22:39] <jelmer> mgz: we use that a lot, I think that's the recommended way of importing modules
[22:40] <mgz> 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] <mgz> you just get a lazy object containing... itself... that then goes away
[22:41] <mgz> I hadn't really thought through what the code I'd written was doing...