[00:24] <chandlerc[g]> jelmer: ping
[00:58] <jelmer> chandlerc, pong
[01:12] <chandlerc[g]> jelmer: i'm working on the segfault
[01:12] <chandlerc[g]> jelmer: but not sure what a good next step is if it doesn't reproduce for anyone else
[01:12] <chandlerc[g]> i'm happy to do any amount of debugging on my end to fix this as its a complete blocker for me at the moment
[01:27] <jelmer> chandlerc[g], I would recommend trying to get the testcase as small as possible, that will help debugging
[01:33] <chandlerc[g]> the test case i posted is the smallest one i can come up with
[01:33] <chandlerc[g]> but it only fails for me
[01:33] <chandlerc[g]> i think its something specific on the two systems i have thats causing it, but i'm not sure how to track that down
[01:35] <jelmer> have you tried running inside valgrind?
[01:35] <chandlerc[g]> how can i do that? run python via valgrind?
[01:35] <chandlerc[g]> (ie, will that put the c code in question under valgrind)
[01:35] <jelmer> yeah, run Python inside of valgrind, indeed
[01:35] <chandlerc[g]> yea, it has to, or gdb wouldn't have worked
[01:35] <jelmer> or something like "make valgrind-check" inside of the bzr-svn directory
[01:39] <chandlerc[g]> yikes
[01:40] <chandlerc[g]>  ERROR SUMMARY: 2084 errors from 139 contexts (suppressed: 172 from 1)
[01:40] <chandlerc[g]> i don't know how useful thats going to be
[01:41] <jelmer> chandlerc[g], did you run with the python suppressions?
[01:45] <chandlerc[g]> what are those?
[01:45] <chandlerc[g]> or how do i find them
[01:46] <jelmer> see the Makefile
[01:56] <chandlerc[g]> jelmer: i'll be continuing my investigations later this evening. In case you're not around, anything in particular I should be looking for?
[01:56] <chandlerc[g]> my other steps are to compile editor.c with full debugging symbols
[01:56] <chandlerc[g]> and hopefully the svn libs as well
[01:56] <chandlerc[g]> let me know if there is anything that would be specifically enlightening here.
[01:56] <chandlerc[g]> i suspect this is going to be a bug in the svn bindings though. =/ un-fun...
[01:59] <jelmer> it could very well be
[01:59] <jelmer> I wonder what's causing the path to be NULL though..
[03:16] <ferringb> hmm.  if I were trying to pull the revids for a specific path, what's the best way- get_ancestry was my first thought, but that seems to just give me all revids for that repo
[03:43] <ferringb> scratch that.  bzrlib.log.find_touching_revisions suffices
[04:20] <kingfishr> When I try to branch a project over ftp, I get "bzr: ERROR: Unable to connect to HOSTNAME; (111, 'Connection refused')"
[04:20] <kingfishr> that's not particularly useful...
[04:20] <bob2> do other ftp clients work?
[04:21] <kingfishr> yes
[04:21] <kingfishr> with passive, too
[04:21] <bob2> anything more useful in ~/.bzr.log?
[04:22] <kingfishr> checking
[04:23] <kingfishr> Not particularly
[04:23] <kingfishr> It's throwing a SocketConnectionError
[04:26] <kingfishr> bob2, would it help if I were to pastebin the logfile?
[04:29] <kingfishr> Ah! got it
[04:29] <kingfishr> I need to use a different port
[04:29] <kingfishr> whoops
[04:32] <bob2> hehe
[04:44] <ferringb> actually... why would bzrlib.log.find_touching_revisions continue on past a delete?  seems like it would be inspecting revs for no reason post delete
[06:51] <chandlerc> jelmer: if you happen to be around, i'm digging in again on this
[07:24] <stefanlsd> I've deleted two tags locally, but want to delete them on the repo in lp now. although i cant seem to push them up. any ideas?
[07:52] <glatzor> hello, when performing an action on my repository I only get the following error message:
[07:52] <glatzor> bzr: ERROR: Could not acquire lock "[Errno 11] Resource temporarily unavailable"
[07:52] <glatzor> /usr/lib/python2.5/site-packages/bzrlib/lock.py:79: UserWarning: lock on <open file u'/home/renate/Entwicklung/gnome-packagekit/ubuntu/.bzr/checkout/dirstate', mode 'rb' at 0xa0a7728> not released
[07:52] <glatzor>   warn("lock on %r not released" % self.f)
[07:52] <glatzor> bzr break-lock is of no help
=== fta_ is now known as fta
=== abentley1 is now known as abentley
=== lamont` is now known as lamont
[15:46] <Leefmc> Question: Anyone familiar with the workflow of having multiple branchs and a working branch, along with needing to download updates from the main launchpad branch?
[15:47] <Leefmc> I'm having trouble figuring a good workflow, without destroying my working branch.
=== doko_ is now known as doko
[16:07] <LarstiQ> Leefmc: what do you mean with destroying your working branch?
[16:07] <Leefmc> LarstiQ: Sorry, read what i said in #launchpad and we'll take it here :)
[16:08] <LarstiQ> Leefmc: I did, but it wasn't really clear to me.
[16:08] <LarstiQ> Leefmc: what do you do that destroys your working branch?
[16:10] <Leefmc> LarstiQ: Well on the destroying my working branch, if i have a working branch /wrk of /trunk, and i am in /wrk and use bzr update, it adds to my /wrk branch. This seems fine, until you notice that now /wrk and /trunk are not the same. /wrk has the updates from lp:* but /trunk does not. You cannot commit the changes to /trunk either, because according to /wrk, no changes have been made
[16:12] <LarstiQ> Leefmc: is /wrk a branch, or a working tree?
[16:12] <LarstiQ> Leefmc: I suspect it's just a working tree from how you described your workflow
[16:12] <LarstiQ> but if not, I'd like to get that confusion out of the way first
[16:12] <Leefmc> LarstiQ: bzr/git have hazed my definitions of this, pardon if i am using them wrong. /wrk is a lightcheckout, thats all :)
[16:12] <Leefmc> lightcheckout of /trunk
[16:13] <LarstiQ> right, a lightweight checkout is just a working tree, good
[16:13] <LarstiQ> Leefmc: so /wrk is bound to /trunk, and then you `bzr update` in /wrk.
[16:13] <Leefmc> I am doing it this way so i can imitate my old git workflow of being able to create test branches of the fly (/trunk, /test, /brokencode, etc) and swap between them without having to move my IDE, etc.
[16:14] <LarstiQ> right
[16:14] <Leefmc> LarstiQ: Correct, because i am trying to avoid the workflow of jumping around, even in terminal.
[16:14] <LarstiQ> Leefmc: that is a common workflow for that situation
[16:14]  * LarstiQ nods
[16:14] <LarstiQ> Leefmc: I'm a bit confused though. Afaics `bzr update` in /wrk should also have updated /trunk.
[16:15] <LarstiQ> Leefmc: could you show me the output of `bzr info -v` from /wrk ?
[16:15] <Leefmc> Well for example, when i did, there were 2 new files downloaded from launchpad, but those two were not in /trunk.
[16:16] <LarstiQ> aaah
[16:16] <LarstiQ> I think I may get it now
[16:16] <LarstiQ> Leefmc: /trunk is not a tree-less branch?
[16:16] <Leefmc> I sort of destroyed all that already, im back to my "pre update" stage of my repo, since i simply copied it before i toyed
[16:16] <Leefmc> LarstiQ: Not sure, what do you mean?
[16:17] <LarstiQ> Leefmc: there are three main domain concepts in Bazaar. Branch, (Working)Tree, Repository
[16:18] <LarstiQ> Leefmc: the repository just stores revisions. A branch is a pointer to a revision in the revision DAG determing a line of development, and a working tree is the actual tree of files so you can edit and commit (plus some metadata)
[16:18] <LarstiQ> Leefmc: they can be in different areas, or in the same directory
[16:18] <LarstiQ> Leefmc: now, if my hypothesis is correct, /trunk is both a branch and a working tree
[16:18] <Leefmc> ah
[16:19] <LarstiQ> Leefmc: the update in /wrk will have updated the branch part of /trunk, but not the working tree part
[16:19] <LarstiQ> Leefmc: you can confirm this by checking for existance of /trunk/.bzr/{checkout,branch}
[16:19] <LarstiQ> Leefmc: the former being the data for a working tree, and the latter for a branch
[16:19] <LarstiQ> of course, my hunch could be wrong
[16:19] <LarstiQ> Leefmc: but please check this :)
[16:20] <Leefmc> LarstiQ: Assuming i understand you correctly, yes there are /trunk/.bzr/checkout & branch directories
[16:20] <LarstiQ> Leefmc: if I'm correct, a `bzr update` in /trunk will bring its working tree up to date with its branch. But in your workflow it does not make much sense to have more than one working tree.
[16:20] <LarstiQ> Leefmc: right
[16:21] <Leefmc> LarstiQ: So first off, for future reference, because i suspect the problem is the same for all my machines then, what did i do wrong when creating my setup of /repo, /repo/trunk, and /repo/wrk ?
[16:21] <Leefmc> LarstiQ: And secondly, what can i do to fix it?
[16:21] <LarstiQ> Leefmc: So, the recommended setup in your case is to have a repository that defaults the branches in it to be tree-less, and then have your branches in there. You can create one with `bzr init-repo --no-trees /project/`
[16:22] <LarstiQ> or repo
[16:22] <LarstiQ> s/project/repo/ in that case
[16:22] <LarstiQ> Leefmc: any branch you will create in that will not have a working tree by default
[16:22] <LarstiQ> Leefmc: to remove trees from branches that have one, you can `bzr remove-tree`
[16:22] <Leefmc> gotcha
[16:22] <Leefmc> LarstiQ: And that will also fix my problem correct?
[16:23] <LarstiQ> Leefmc: your branches will no longer have working trees, so you shouldn't get confused anymore
[16:23] <LarstiQ> Leefmc: is /trunk in a shared repository? bzr info will tell
[16:23] <Leefmc> LarstiQ: Would i be able to simple dump everything, create a new repo (bzr init-repo --no-trees /repo) and create a new trunk (bzr init /trunk) and a new working dir (bzr checkout --lightweight /trunk /wrk) ?
[16:24] <LarstiQ> Leefmc: you could, but then you'd lose work?
[16:24] <Leefmc> LarstiQ: Yes, it says that /repo is the shared directory. (trunk is in /repo/trunk)
[16:24] <LarstiQ> Leefmc: ah cool
[16:25] <LarstiQ> Leefmc: you can also change your existing repo to be tree-less from henceforth
[16:25] <Leefmc> LarstiQ: My work is on my other machine, and soon i am going to push it to launchpad to replace the fowlups i've made when trying to figure this out. (I updated /wrk and then made a change and commited to see if it would commit to /trunk, but instead it uploaded to launchpad)
[16:25] <LarstiQ> Leefmc: ok, that sounds as if /wrk is not actually bound to /trunk?
[16:26] <LarstiQ> Leefmc: just to be clear, when we're talking about /trunk we mean /repo/trunk, and not something else outside of /repo?
[16:26] <Leefmc> LarstiQ: It was a lightcheckout, but beyond that i do not know. I may have changed something aswell in my misguided search for information and understanding
[16:26] <Leefmc> LarstiQ: Yes, /repo/trunk, pardon my lazy typing :)
[16:27] <Leefmc> LarstiQ: All mentions of /wrk and /trunk have really been /repo/trunk and /repo/wrk
[16:27] <LarstiQ> good, good
[16:27] <LarstiQ> Leefmc: I'm fine with lazy typing, just want to make sure I'm not assuming a situation which isn't true :)
[16:28] <Leefmc> LarstiQ: So am i correct in the understanding that bazaar "needs" a working tree? (or working branch.. im still confused on the difference of branch/tree, but i can get that from a re-read of the bzr intro)
[16:28] <LarstiQ> Leefmc: `bzr info` is the goto command to find out where /wrk is bound to :)
[16:29] <Leefmc> LarstiQ: It says that the lightcheckout root is ".", the repo checkout root is /repo/trunk, and that it is a checkout of branch lp:myproj
[16:29] <LarstiQ> Leefmc: you need a working tree to edit files/commit etc. But not for publising changes and such. launchpad hosts branches, there are no working trees there.
[16:29] <Leefmc> gotcha
[16:30] <LarstiQ> Leefmc: a lightweight checkout provides a working tree that says "my branch is over <there>, go bother it for more information"
[16:31] <Leefmc> yea
[16:31] <LarstiQ> Leefmc: so for you, I'd keep to having just that one for a working tree, no others.
[16:31] <woeye> greetings all. following the discussion a bit. what is the difference between a lightweight checkout and a symbolic link then?
[16:32] <woeye> (i am currently reading a bit about bazaar and whether it would makes things easier for me - coming from git *g*)
[16:32] <LarstiQ> woeye: the branch you're linking to might not have a working tree. Or it might exist somewhere else on the network.
[16:32] <woeye> ok, I see. especially the network thing is an important one. forgot that ;)
[16:33] <LarstiQ> woeye: but especially the first one is important imo
[16:33] <Leefmc> LarstiQ: Im still a bit confused on how it let two working trees (/wrk and /trunk) play off eachother. Understanding of that will come with experience i assume :)
[16:33] <LarstiQ> woeye: if you'd use a symlink, bzr switch would then point the symlink somewhere else, so far so good. But every branch you point to would need to have a working tree, or get one created at switch time.
[16:34] <woeye> yeah, I see
[16:34] <LarstiQ> woeye: you can imagine the pain if you have a couple of trees of, say, mysql laying around and need to recompile from scratch every time
[16:35] <woeye> do you know django? I think that lightweight checkouts would make the handling of "shared app" folders way easier
[16:36] <LarstiQ> woeye: Heard of, but not actually familiar with.
[16:36] <woeye> django allows to share python packages between projects (web applications)
[16:37] <woeye> typically you have a folder where all shared code goes in
[16:37] <LarstiQ> woeye: django specific site-packages vs zc.buildout for each webapp?
[16:38] <woeye> sort of. the thing is, sometimes you need different versions of the shared code. or you would have to keep every depending web app up-to-date
[16:38]  * LarstiQ nods
[16:39] <woeye> (which is currently my problem ;) )
[16:39] <Leefmc> LarstiQ: Anyway, imma hop on my othermachine and overwrite my bad pushes. Thanks again LarstiQ, you've been a huge help!
[16:39] <LarstiQ> woeye: the concept has been drilled into me the last couple of PUN meetings ;)
[16:39] <LarstiQ> Leefmc: pleased to be of help! If you have any more questions, you know where to find me :)
[16:39] <woeye> so, what i need is a web app container folder which contains the code for the app itself and a lightweight checkout of a shared code branch
[16:41] <woeye> of course I could also have different branches floating around. but things get very confusing quickly
[16:42] <woeye> what I like about bazaars approach is to have a central repo where all projects reside. easier to maintain imho.
[17:02]  * LarstiQ heads out for dinner
[17:03] <LarstiQ> woeye: do you have a link describing this?
[17:03] <woeye> hm, let me see ...
[17:05] <woeye> this wiki page describes it a bit: http://code.djangoproject.com/wiki/BestPracticesToWorkWith3rdPartyAppsAndMakingYoursPortable
[17:07] <woeye> now, the main feature for me is that I can have a central repo where all projects (and all releases) reside and build some kind of virtual structures with lightweight checkouts.
[17:07] <woeye> having lots of git branches floating around on my disk is not so cool
[17:37] <Leefmc> LarstiQ: So if you do not have a working tree, you cannot even _see_ the contents of a branch? (ie, /trunk/somefile.py will not be shown?)
[17:55] <clemente> „bzr shelve“ is asking me „Shelve this change?“ but it shows me actually two changes which are very close. The blocks are: added chunk, common line, removed line, added chunk. That common line sets them apart
[17:55] <clemente> It would be good if it had something like a „b“ option to break that change appart in smaller chunks
[18:07] <woeye> bzr status doesn't show files recursively? there's only bzr add --dry-run for this?
[18:08] <fullermd> What do you mean, doesn't show recursively?
[18:08] <woeye> subdirectories of subdirectories
[18:08] <fullermd> It shows the whole tree, unless you limit it.  And even then, it descends into the whole subtree you specify.  I don't think it even HAS a --no-recurse...
[18:09] <woeye> when I did a bzr init followed by a bzr status I could only see the status of the current top level directory
[18:10] <fullermd> Oh.  It won't descend into unversioned directories, no.  They're none of bzr's business until you tell it to care about them.
[18:10] <woeye> ok
[21:35] <vadi2> Hi, I have a question - how can I move bzr into one folder below? I accidentally made the branch above the root folder of the project.
[21:39] <AmanicA> vadi2: did you do much in it yet?
[21:41] <AmanicA> vadi2: you can either just delete the .bzr and init the real root (and loose all history)
[21:44] <AmanicA> vadi2: or, (make backup first!) say your structure is /myproject/subfolder/.bzr  then do cd /myproject/subfolder; bzr mkdir subfolder; bzr mv files subfolder
[21:46] <AmanicA> vadi2: mv ../root_files . ; cd ../.. ; mv myproject myproject.old mv myproject.old/subfolder myproject
[21:48] <kimus> hi, need help configuring a hook on a repository. where's the plugins directory on the repository?
[22:00] <vadi2> AmanicA: no it's above, so it's /.bzr/myproject
[22:00] <vadi2> AmanicA: other non-project files are currently set as "unknown"
[22:01] <AmanicA> vadi2: so say its projects/myproject with projects/.bzr
[22:02] <kimus> can anyone can help me on how to create a hook on bzr on the repository?
[22:03] <vadi2> AmanicA: it's actually .bzr in projects and projects/myproject
[22:03] <AmanicA> vadi2: try again: so say its /opt/projects/myproject with /opt/projects/.bzr
[22:03] <kimus> does bzr support hooks on the repository?
[22:04] <vadi2> yes
[22:04] <kimus> vadi2: yes? how?
[22:04] <fullermd> I don't think it does, actually.  Only hooks on the branch.
[22:04] <vadi2> sorry, that was to AmanicA. I'm not familiar with bzr coding
[22:05] <kimus> i want to do something on the server on evry commit
[22:05] <kimus> it's this possible?
[22:05] <vadi2> every commit, yes
[22:05] <vadi2> there is a publish bot that does something on every commit
[22:05] <kimus> vadi2: goo, how?
[22:05] <vadi2> though it's local to the user
[22:05] <vadi2> not server
[22:05] <vadi2> i don't know, you can look at it's code though
[22:05] <vadi2> sec...
[22:05] <fullermd> I don't know if the smart server supports running hooks yet or not.
[22:05] <kimus> what? local to the user??
[22:05] <vadi2> yes.
[22:05] <kimus> so back to svn then...
[22:06] <vadi2> like I said
[22:06] <vadi2> I've seen this one plugin do it
[22:06] <vadi2> I don't know if bzr supports hooks or no.
[22:06] <vadi2> if you're interested, read the api or something
[22:06] <AmanicA> vadi2: cd /opt ; mv projects myproject; mkdir projects; mv projects.old/otherprojects projects; cd myproject; bzr mv myproject/files . ; rm myproject
[22:06] <kimus> the only hooks I saw was for the plugins dir... and I bet it's only for user not the server :-S
[22:07] <AmanicA> kimus: yes you can run hooks on the server, what protocol are you intending to use?
[22:07] <vadi2> I cannot guarantee anything. But you do know about loggerhead?
[22:07] <kimus> AmanicA: anyone that does the job. i'm testing with ssh now
[22:08] <AmanicA> kimus and fullermd, you'll need 1.8 or dev version to get it to work (the patch I made was only merged recently)
[22:08] <kimus> dev version??... ouch
[22:09] <AmanicA> kimus: to get the hooks to be kciked off you'll need a smart server i.e. bzr+ssh or bzr+http etc.
[22:09] <AmanicA> kimus, I run it in production, cos I have to be current
[22:09] <kimus> I'm testing on bzr+ssh protocol now
[22:09] <AmanicA> you can try the 1.8rc
[22:10] <kimus> AmanicA: I can try... but what's the confs?
[22:10] <AmanicA> (my patch was for bzr+http)
[22:10] <kimus> I have to configure something right?
[22:10] <kimus> AmanicA: only works on bzr+http ?
[22:11] <AmanicA> dont think so, I havn't used bzr+ssh much, but I think the hooks should work
[22:11] <kimus> AmanicA: let's say it works. what I need to configure for the hooks work? where to put the .py scrits?
[22:12] <AmanicA> hooks are plugins
[22:12] <AmanicA> and plugins go in site-package/bzrlib/plugins or ~/.bazaar/plugins
[22:13] <vadi2> AmanicA: instead of "bzr mv myproject/files .", can I use "bzr mv myproject/* ."
[22:13] <AmanicA> there is a plucing which lets you configure it to run scripts
[22:13] <kimus> so the plugins are system wide and not only for a repository  ?!?!?
[22:13] <vadi2> there are a lot of files there to move manually
[22:13] <AmanicA> vadi2 no
[22:13] <AmanicA> vadi2: cos youre moving it out of the branch
[22:13] <AmanicA> kimus: yes
[22:14] <kimus> AmanicA: wtf! that it's a bit stupid :-S
[22:14] <AmanicA> but kimus you might be able to cnfigure the shell_hooks plugins to run different scripts depending on the location
[22:14] <AmanicA> kimus youre just used to svn
[22:14] <kimus> AmanicA: cvs works fine also :-p
[22:14] <AmanicA> kimus: does svn have a way to install hooks globally?
[22:14] <kimus> with cvs I can co and commit the hooks :-)
[22:15] <vadi2> AmanicA: thanks for your help
[22:15] <AmanicA> kimus: interesting
[22:15] <AmanicA> vadi2: did it work?
[22:15] <sky-g> kimus: I was just looking at the package etckeeper (tip from a guy in #git).  It uses hooks and supports bzr and has some bzr sample code to install a hook plugin (I think)  Whether this is for local or what you refer to as "server" I couldn't say
[22:16] <vadi2> AmanicA: no, error, but it's ok to just start with a clean history as the past isn't too important at this point
[22:16] <AmanicA> cool
[22:17] <kimus> AmanicA: ever repository has different types of needs regarding hooks (building, mirroring, etc) because they can be diferent languages and tipes
[22:17] <kimus> *types
[22:18] <kimus> so, a global hook is not has good has repo only hooks
[22:18] <fullermd> The hook code is global.  That doesn't mean every branch has to invoke it.
[22:19] <kimus> fullermd: only know one way... some IF's on the hook :-p
[22:19] <sky-g> kimus: you're right.  but a hook is a hook... it's open, so you should be able to write your script to do stuff only when it's appropriate (e.g. for a certain repos) right?
[22:20] <sky-g> what's wrong with ifs? :-)
[22:20] <kimus> sky-g: sure... but not ideal. it should have a configuration on the repo to add hooks
[22:20] <fullermd> They get lonely without ands and buts   :p
[22:20] <kimus> did you saw: http://bazaar-vcs.org/BzrHooks ?
[22:21] <fullermd> There's no configuration on the repo.  There's only configuration on the branch.
[22:21] <kimus> fullermd: whatever. a conf in branch it's ok for me
[22:22] <fullermd> Your hook would just need to have an _enable switch that the branch sets.
[22:22] <kimus> fullermd: didn't understood what you said
[22:23] <fullermd> There's also the shell-hooks, but I don't know how well that works.
[22:23] <sky-g> etckeeper example, if it helps: http://pastie.org/290221
[22:23] <fullermd> Well, your plugin has access to all the same config as the rest of bzr.  So it could just check if "frobnicate_enable" is set.
[22:27] <kimus> sky-g: I'll check that... but for me is a workaround it should be possible to configure hooks (by the client) on the repo/branch
[22:34] <kimus> sky-g: i can do what a .py don't need the etckeeper. i can do my IFs :-D
[22:56] <chandlerc[g]> jelmer: jsyk, i've now re-produced this madness on a freshly built, debugging enabled python. talking to python guys to try and figure out how the invariant for that function is violated
[23:00] <jelmer> chandlerc[g], hi
[23:00] <jelmer> chandlerc[g], reproduced it without bzr(-svn) ?
[23:00] <chandlerc[g]> no, but *any* call to that method returning a null pointer is broken
[23:01] <chandlerc[g]> and if you know of anything i can do inside of gdb, at the point it does this, with a full debugging python interpreter, its sitting here
[23:01] <chandlerc[g]> i don't know enough about python to know how to manipulate the self object and dig out the context for this call
[23:22] <chandlerc[g]> jelmer: bzr-svn rocks. =] using it on the non-messed-up system, and its shoving revisions into subversion perfectly
[23:22] <chandlerc[g]> despite it being branched around 3 ways to get it from the broken machine to the working one, and developed on and off for a month across both machines
[23:54] <jelmer> chandlerc[g], sorry, my knowledge of Python internals is a bit limited as well in that regard
[23:54] <jelmer> chandlerc[g], glad you appreciate bzr-svn, pity you're hitting this issue though :-(
[23:58] <chandlerc[g]> jelmer: i'm about 99.9% confident its a python issue
[23:58] <chandlerc[g]> rather, a python + svn issue
[23:58] <chandlerc[g]> i'm not going to loose sleep over it when it works on Ubuntu, and doesn't on Gentoo. i'll wait for updates to the whole damn thing