billy | hi folks - can bzr-svn import a subversion repository? | 00:12 |
---|---|---|
lifeless | yes | 00:12 |
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:15 |
billy | anyone? | 00:19 |
lifeless | sorry, got stuff happening here | 00:20 |
lifeless | have you read the user docs on migration? they are pretty good I think | 00:20 |
billy | lifeless: no - they are woeful | 00:22 |
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:45 |
billy | james_w: trying now | 00:46 |
billy | james_w: while i'm waiting the error said use 'bzr branch' so would 'bzr svn-import branch' be a valid command? | 00:49 |
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:55 |
billy | maxb: thanks | 00:56 |
=== Ursinha is now known as Ursinha-afk | ||
=== Ursinha-afk is now known as Ursinha | ||
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:14 |
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:15 |
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:16 |
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:19 |
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:20 |
Ddorda | i had conf problem with ssh. trying now again | 11:22 |
Ddorda | okay, i found what was the problem. it was ssh configuration problem | 11:23 |
lifeless | cool | 11:24 |
Ddorda | lifeless: many thanks | 11:24 |
lifeless | np | 11:24 |
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:01 |
jelmer | Pilky: that should work | 15:03 |
Pilky | and I assume merging can be done locally so git and bzr manage it, rather than having to fight with svn? | 15:04 |
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:11 |
jelmer | :-) | 15:16 |
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:17 |
mgz | it's not very careful in ensuring what it's creating is actually well-formed | 17:18 |
mgz | I think I will not worry about that right now and just fix the import like I was going to. | 17:20 |
mgz | ...aren't plugins meant to import their bits from bzrlib.plugins rather than the root namespace? | 17:22 |
jelmer | mgz: yes | 17:41 |
mgz | ugh, I'm failing to see a way to fix this without fixing one of several larger problems | 17:47 |
jelmer | mgz: What are you trying to do with bzr-xmloutput? | 18:05 |
mgz | jelmer: https://bugs.launchpad.net/bzr/+bug/614522 <- comment #2 | 18:51 |
ubot5 | Launchpad bug 614522 in Bazaar "Monkey patching private escaping functions breaks with ElementTree 1.3 (affected: 1, heat: 6)" [High,Fix released] | 18:51 |
jelmer | ah, hmm | 18:52 |
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 | 18:54 |
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:14 |
jelmer | mgz, whoa | 19:33 |
mgz | I good number are from a bug I noticed earlier and nearly commented on in here | 19:34 |
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:35 |
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 | 19:48 |
lifeless | mgz: hi | 20:49 |
mgz | hey lifeless. | 20:49 |
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:50 |
mgz | intern needs str objects on 2.4 at least. | 20:51 |
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:52 | |
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:53 |
lifeless | yeah | 20:55 |
lifeless | this is 2.5 breaks, 2.6 works | 20:55 |
lifeless | 2.5 is of course only accessible in an ec2 instance. | 20:56 |
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 | 20:59 |
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:03 |
lifeless | ok | 21:04 |
lifeless | so that one can be fun | 21:04 |
lifeless | calling gc.collect() can cause it | 21:04 |
lifeless | IIRC, alternatively it was using gc.objects can trigger it | 21:05 |
lifeless | either of those being done? | 21:05 |
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:06 |
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:08 |
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:09 |
mgz | there's a place for end-to-end testing, just... not everywhere please ;_; | 21:10 |
fullermd | Of course not. Only at the ends 8-} | 21:19 |
=== Leonidas_ is now known as Leonidas | ||
mgz | okay, this is so far from where I started, but the lazy_import thing is starting to make sense | 22:04 |
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:05 |
mgz | ...okay, this is funny, and stupid. | 22:16 |
mgz | okay, fixed, and I'm going to poke bzrlib so no one else gets into that kind of tiz again | 22:37 |
mgz | summary, "from thispackage import module" is a bad idea | 22:38 |
jelmer | mgz: we use that a lot, I think that's the recommended way of importing modules | 22:39 |
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:40 |
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... | 22:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!