[00:00] Wait, what about plugins? [00:00] * Peng wanders off. [00:04] lifeless: there you are then [00:06] spiv: Hmm, that's an interesting bug [00:07] slangasek: I can't think of a reason a by-value joined tree wouldn't work [00:07] jelmer: something weird also happened when there were revisions [00:07] jelmer: it pushed ok, but the merge to trunk caused some sort of property conflict [00:07] spiv: That's the bit I mean [00:07] spiv: bzr svn-push can't use a clean "svn cp" [00:09] jelmer: hmm, why not? [00:09] spiv: if there is a branch A with tip revision 42 and you're trying to push a branch B that also has tip 42 it has to do a copy of r41 -> /B that replays the changes in r42 [00:09] otherwise the two branches actually have a different revision history [00:10] A has tip 42 and B has tip 42+1 where rev 1 is en empty commit that changes the branch nick from A to B [00:11] New bug: #203376 in bzr "traceback when merging an svn repo with a 'bzr join'ed branch" [Undecided,New] https://launchpad.net/bugs/203376 [00:12] slangasek: thanks [00:12] spiv: ^ [00:12] jelmer: hmm, because you can't easily figure out that the tip 42 in B happens to be the same as 42 elsewhere in the repo? [00:13] spiv: I can figure that out, but the problem is that B has more revisions than A [00:14] the commit that contains the "svn cp" will show up as well [00:14] Ah, the impedence mismatch, because making a branch in bzr doesn't make a revision. [00:14] But in svn it does. [00:15] I think I see. [00:15] yep, that's a clearer way of explaining it [00:15] so a cp that makes no alterations should not generate a revision in the mappings [00:15] :) [00:16] lifeless: yep, but there are performance considerations there [00:21] hay guise [00:21] sry for bzr-svn bgz [00:31] jelmer: I think I'll recommend people like the Twisted guys should just keep using "svn cp" for the initial branch in the repo. [00:35] New bug: #203381 in bzr-svn "Error when pushing 0.4.8 to a branch that exists in svn." [Undecided,New] https://launchpad.net/bugs/203381 [00:38] jelmer: btw, your versionedfile thunks in bzr-svn will need updating soon :) [00:40] spiv: Makes sense [00:41] spiv: We could potentially add a create-svn-branch command [00:41] lifeless: Which thunks? :-) [00:41] jelmer: yeah, I was thinking about that. I'm not sure if I like the idea or not :) [01:11] jelmer: do you not have an implementation of repo.text_store.get_weave ? [01:16] I'm trying to convert a git repo to a bzr repo and I'm running into the same problems described here: https://bugs.launchpad.net/bzr-git/+bug/181811 [01:16] Launchpad bug 181811 in bzr-git "bzr-git incompatible with certain stgit versions" [Undecided,New] [01:16] the problem is that when I do the last instruction, it tells me that my converted directory isn't a branch [01:25] mxpxpod: I suggest you look into bzr fast-import [01:28] lifeless: hrmmm... the git in gutsy doesn't provide git-fast-export :( [01:29] wow i had no idea of http://www.python.org/dev/peps/pep-0292/ [01:29] least of all that it was in 2.4 [01:34] lifeless: nope, don't need it [01:34] lifeless: the only place where versionedfile is used is in the fetch code [01:39] jelmer: and annotate [01:39] jelmer: and repository stacking [01:39] Random thoughts.... a 'TODO counter' plugin... Keep a track of how many 'TODO' comments I still have in checked-in code [01:39] Plus maybe a daily email of "Here's some things left to do:" with a few lines of context [01:43] poolie: people never expect to find new functionality in the string module :) === _jgreenwa is now known as jetsaredim [01:51] lifeless: repository stacking isn't supported yet [01:51] lifeless: nor is annotate on remote svn files [01:57] jelmer: so, to stack we'll need this [01:58] yay internode, you go [01:58] jelmer: so, to stack we'll need this [01:59] lifeless: thanks for the tip... I just compiled git from hardy for gutsy and the fast-import worked flawlessly [02:00] lifeless: the main reason I haven't bothered to look at it yet is because performance on directories will suck badly [02:00] jelmer: I don't think that that is a good reason not to do it ;) [02:01] hmm bzrtools complaining [02:01] lifeless: well, in either case it's probably better to wait until the new vf api lands :-) [02:01] time to edit off the version check again [02:08] jelmer: should I be running released bzr-svn or trunk bzr-svn? [02:09] LeoNerd: I've thought about that. [02:10] LeoNerd: To do it right, that plugin would need to be language-aware. [02:14] poolie: finally heading to yours. [02:15] jml: Depends on what version of bzr you'r eusing :-) [02:16] jml: 1.2 -> released bzr-svn, bzr.dev -> bzr-svn's bzr branch === kiko is now known as kiko-zzz === lamont` is now known as lamont [02:42] jelmer: btw, why would directories be slow ? [02:50] lifeless: there's no way to get all the interesting revisions for a directory [02:50] it is possible for a file [02:50] dir copies are not explicit ? [02:51] lifeless: they are, but there is no call in the svn smart server protocol to retrieve the interesting revisions for a particular dir [02:55] garh [02:56] about a page of deprecation warnings to go [03:23] ugh. bzr shelve uses __methods [03:47] how can i unlock a repo? i had a commit message window open and my ssh link died [03:47] kgoetz: bzr break-lock URL [03:48] poolie: i get a reply of "bzr: ERROR: The lock for '/home/kgoetz/public_html/dansitev01' is in use and cannot be broken." [03:52] hm [03:53] is there still a bzr process running on that machine by any chance? [03:53] let me check [03:54] yes there is. theres a `bzr ci` running still [03:56] poolie: thanks for pointing that out - killed the process and the break-lock worked [03:56] you're welcome [04:45] night all [04:56] igc: night [04:57] igc: you jetlagged ? [05:45] and i shold be here [05:58] lifeless: symbol_versioning patch sent [05:59] thanks [06:11] poolie: k, I'm done for the day; this is I think the hardest of the apis to adjust, because of the ghost implications, and its nearly done. [06:11] poolie: couple of failing tests still [06:52] jml: whats wuhi ? [06:53] lifeless: We Haven't Used It [06:53] I could *swear* I've read it in some agile manifesto before. [06:59] ah [07:02] hmm, wouldn't that be whui? [07:22] TFKyle: yes. there was a typo somewhere along the way. [07:27] I object to that, I'm not a typo. I'm a hoomarn bean [07:32] lifeless: have you seen this? http://code.google.com/p/python-safethread/ [07:37] "base (single-threaded) throughput is only around 60-65% that of normal CPython" [07:52] i386: no, I haven't === mwhudson__ is now known as mwhudson [11:56] bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Ermurri/vc-bzr/emacs22.1/.bzr/repository/lock): Transport operation not possible: http does not support mkdir() [11:57] you can't push over http [11:57] that was a pull [11:57] no idea then [11:57] bob2: are you running the latest version? [11:58] 3295 [12:02] ah, it was a heavy weight checkout [12:04] ah, ok. === AnMaster_ is now known as AnMaster === mrevell is now known as mrevell-lunch === FreeNode is now known as herb [12:56] does anyone know if a new bzrtools release is scheduled to appear 'soon'? [13:06] hi siretart [13:06] I haven't heard. [13:06] Aaron is normally pretty prompt [13:12] hi james_w [13:12] I've now built a debian package for myself based on what's currently in bzrtools.dev [13:13] however the testsuite (not run during package build) fails [13:13] I've considered uploading it to debian to get bzrtools and bzr-builddeb installable again [13:18] i heard as part of emacs discussions, some performance improvements have been proposed or checked in? [13:19] I am interested in testing for performance, could someone give me extra information how to test bzr for performance === mrevell-lunch is now known as mrevell [13:28] 'bzr --profile command whatever' might be of use === herb is now known as herb__ === herb__ is now known as herb === spiv_ is now known as spiv [14:35] Is there some trick to being able to use bzr normally on an NFSv4 mounted home directory? === kiko-zzz is now known as kiko [14:40] mbt: what do you mean normally? [14:41] Without errors... Nearly everything I do is accompanied by an "bzr: ERROR: [Errno 5] Input/output error" when using it on an NFSv4-mounted home, but when on the local filesystem, I do not get this error. [14:41] For example, I get that error when I bzr diff [14:41] or bzr status [14:42] mbt: the error traceback would be useful to see. [14:42] james_w: Is there a way to make it generate one? [14:42] It just shows the Errno 5 message. [14:42] mbt: bzr -Derror diff [14:43] james_w: http://pastebin.com/d1561bfcd [14:46] mbt: ok, so it's having some problems removing the lock. [14:48] Should I go ahead and file a bug, then? I would presume that it is supposed to work on an NFS-mounted home, right, or is that outside of what bzr is expected to do? [14:54] mbt: is https://bugs.launchpad.net/bzr/+bug/137387 it? [14:54] Launchpad bug 137387 in bzr "UserWarning: lock not released cluttering user output" [High,Triaged] [14:56] morning [14:56] hi igc [14:56] james_w: It might be, but I am not sure. [14:57] james_w: Let me see if I can coax bzr into giving me more details [14:57] hi james_w [14:59] igc: fast-import broke for me. I haven't had time to debug it yet. [14:59] james_w: just send me the traceback [14:59] I added tag support last night [15:00] well, lightweight tags at least [15:00] might be that? [15:00] Is there a way to generate a log file as is shown in that bug report, james_w? I can't seem to find it. [15:00] igc: no, it was before that. [15:00] mbt: ~/.bzr.log [15:01] igc: it's bzr-fast-export | bzr fast-import on bzr.dev [15:01] Is it possible with bzr to work with multiple branches out of one directory and switch between them, similar to git? [15:01] james_w: ok, I'll try that. How far though was it previously? [15:02] Or actually, I should just state what my problem is first and see if there is any better way to do what I'm doing in bzr: [15:02] igc: it did all bzr-fast-export could export. [15:02] igc: let me upload the dump for you. [15:03] We have a pretty large codebase in bzr at work now, and each time I make a branch it takes a long time to branch the remote mainline to a local directory because it's pulling down all the source. [15:03] bratsche: are you using a shared repository locally? [15:04] it's highly recommended to do that [15:04] No, the shared repo is on the server. [15:04] Let me search for how to do a shared repo locally. [15:04] bratsche: you definitely want a shared repo locally as well [15:04] it looks like that might be the bug... though the workaround in it does not work, and I still get problems... sigh [15:04] bratsche: a shared repository is just a way of sharing data between branches so you can do it anywhere. [15:04] it's covered in the User Guide [15:05] igc: Right now I do: bzr branch ; bzr checkout [15:05] bratsche: ouch [15:05] igc, james_w: Awesome, thanks very much! I'll search for how to set that up. [15:05] are remote-mainline and remote-branch-url sharing a shared repo? [15:05] james_w: Yes. [15:06] igc: http://jameswestby.net/scratch/bzr-export.txt [15:06] though it is about 20MB, so you may prefer to just generate it locally. [15:06] james_w: I'll generate it locally [15:07] It's just bzr-fast-export.py bzr.dev, right? [15:07] yep. [15:08] Afternoon. [15:09] So I want to do like: bzr init-repo my-local-repo ; cd my-local-repo ; bzr branch ; bzr checkout [15:09] To setup my local shared repo? [15:09] http://pastebin.com/d2f120d12 -- james_w, should I add that info to bug 137387? [15:09] Launchpad bug 137387 in bzr "UserWarning: lock not released cluttering user output" [High,Triaged] https://launchpad.net/bugs/137387 [15:09] And then when I create new branches, I would branch from the local repo? [15:10] hi Odd_Bloke [15:11] bratsche: You only need to do one of branch or checkout there. [15:11] bratsche: repositories are just an optimalization, you can ignore them and just use the workflow you had before [15:11] mbt: yeah probably [15:11] but with a repo it won't download everything [15:11] mbt: if you could debug why these errors occur that would be great. [15:11] because you already have the revisions [15:12] So I create my repo, and just checkout ? [15:12] james_w: o/ [15:12] bratsche: Within the repo, yeah. [15:13] Odd_Bloke: What about when someone else at work posts a branch on the server, and I want to switch over to view it? [15:14] bratsche: switch the existing checkout? [15:14] if so, 'bzr switch ' [15:14] Okay, thanks. [15:14] bratsche: Or you can checkout that branch into a different directory in the repository. [15:14] I'd better go read some more about repos rather than ask all of this here. [15:14] Sweet. [15:15] Thanks everyone. [15:16] bratsche: there is also "bzr help repositories" that explains a little bit [15:17] james_w: I would love to help debug it, but I am not sure where I would even start on it. I know next to nothing about file locking and filesystems. All I really know at this point is that bzr on local reiserfs works perfectly, on nfsv4, it doesn't. [15:20] arrgh. === mb1 is now known as mbt [15:21] Was my last msg about reiserfs/nfs/etc received? [15:21] yeo [15:22] well I'm not sure if it's a locking problem in terms of flock() etc., or just the way that we are creating lockdirs [15:22] k wasn't sure if that actually got out before my client crashed lol [15:22] I don't know the lock code at all though I'm afriad. [15:23] Well, I can try to poke around it at some point this evening, but I have to finish setting up my network, because it's been restructured (which is actually how I found this issue lol). [15:25] jelmer: when is the 0.4.8 release? :) === ja1 is now known as recover === recover is now known as ja1 === ja1 is now known as jma === jma is now known as jam [15:38] jelmer: Should be able to have another crack at building that binding on Friday [15:38] jelmer: A bit busy until then. [15:39] spiv: I'm trying to get it done before 1.3 [15:39] spiv: I hope to get the pyrex stuff in before then [15:56] New bug: #203598 in bzr "Bzr should remember all locations and provide nicknames" [Undecided,New] https://launchpad.net/bugs/203598 [15:57] jelmer: ah, ok. [15:59] jelmer: personally I'd probably release 0.4.8 without pyrex, and if you happen to make a 0.4.9 (or even 0.5.0...) with pyrex a week later, then that's fine. [15:59] jelmer: but I do sympathise with wanting to minimise churn [16:08] jelmer: would you like other people to test your pyrex branch, btw? [16:14] spiv: well, there is one bug which still needs fixing [16:14] spiv: do you have any pyrex experience? [16:15] jelmer: a little bit [16:16] spiv: I'm trying to get pyrex to not return NULL from a cdef function when an exception is being raised [16:16] can someone please tell me again command for changing branch into lightweight checkout? [16:17] hsn_: I think reconfigure can do it === ja1 is now known as jam_ [16:18] spiv: that's the main bit that's preventing the pyrex branch from working [16:19] james_w: yes, thats right [16:30] New bug: #203607 in bzr "bzr unable to upgrade pack-0.92 to rich-root-pack format" [Undecided,New] https://launchpad.net/bugs/203607 [16:34] * lamont has a stupid-bzr question.. [16:34] hrm.. [16:34] nm [16:36] The stupid-bzr plugin isn't compatible with the current bzr version I'm afraid === kiko is now known as kiko-fud [17:30] hmm.. that was a very long question [17:30] I seem to have missed it completely :) [17:31] Hey [17:31] I am just trying to branch a remote svn repository (over https) [17:32] bzr-svn is installed [17:32] this is the result: http://paste.pocoo.org/show/34207/ [17:35] jelmer: ^^^ [17:38] dennda: can you try bzr branch svn+https://svn.example.com/myrepo [17:49] moin [17:49] james_w: thanks, that works [17:49] james_w: but how to tell bzr how to push to that location? [17:50] nevermind [17:50] just figured it out [17:50] thanks [18:03] dennda: see the FAQ [18:04] dennda: never mind, I was reading backlog [18:11] New bug: #203643 in bzr "'bzr status' crashes with MemoryError" [Undecided,New] https://launchpad.net/bugs/203643 [18:41] hi [18:42] i'd like to propose bazaar instead of cvs but there are 2 question about it.Could you help me ? [18:42] sure [18:44] 1) it seems impossible to retag single files (example i need to create a package with old files labelled AAA and i want to add 2 files in HEAD) === kiko-fud is now known as kiko [18:45] lopio: sorry, I don't understand the question, could you explain it a little more please? [18:45] in CVS i'll extract old label AAA and i'll force a retag AAA on the 2 files [18:45] ok [18:45] lopio: no, bzr doesn't have per-file tags [18:46] (or per-file revisions, like cvs) [18:47] in bzr you would normally branch of the tag AAA and then merge the changes to those 2 files from HEAD [18:48] i see luks but in this case i'll have a new branch forever [18:49] is that a problem? [18:50] it is a problem when you have a schema with central repository.... [18:50] lopio: if you want the old versions of two files then you can use revert to get them, and then commit to include them in your current HEAD [18:50] well, tag in bzr applies to the whole tree [18:51] so if you don't have such tree in your branch, you need to create it [18:51] ok [18:51] this is not a blocking problem -) [18:51] Now a real problem -( [18:52] but generally you would have this problem with any VCS that isn't CVS [18:52] I don't know of any other VCS that works on file basis [18:52] CVS is old but is able to manage CRLF [18:53] and this is a real problem for us [18:53] siretart: I'll try to have it out this evening. [18:53] we have a central CVS repository and we are able to co and commit in XP and HP both [18:54] this is because in CVS you have to specify -kb parameter when you add an exe file [18:55] in this way when you checkout under XP a CR is added to files different from exe (and removed during commit) [18:56] lopio: we want to add support for line endings, but it is not done yet. [18:57] this is a strong limitation i think -(((((((((( [19:00] It seems a marvellous versioning system so i hope some people could add this feature as soon as possible [19:01] keep up the good work!!! Thank you very much...see you later..bye [19:05] james_w: fyi - fast-import is better now wrt renaming handling [19:06] a bug still exists though [19:06] it now gets a lot further on your bzr.dev export but not all the way through [19:07] I'm moving onto some other stuff now so it might be a day or so before I get back to this === luks_ is now known as luks [20:01] anyone know of tool to completely remove files from my bzr history? [20:02] mamato_: no such tool exists yet I'm afraid. [20:04] weird... [20:07] bzr strongly discourages rewriting history [20:11] hmm... should have maybe sticked to rcs then :S [20:12] you might be able to use rebase, especially if the file hasn't changed much over history [20:12] * mamato_ strongly encourages cleaning up one's crap when needed [20:13] i guess we could have an argument about that [20:13] but i can't really be bothered [20:17] mamato_: the only compelling use-case I can see for changing history in a good VCS is when "sensitive" data has accidentally gotten into the repo [20:17] e.g. passwords [20:23] i need versioning for personal code... i'm the only user... for the first project i used it, i realized that i had accidentally checked in tons of images which dont need versionning... couldn't back up my branch to the internet like i wanted... had to loose all my change history weeks after... if a 'good VCS' doesn't allow it, maybe that's not what i need... [20:25] all i want is a 'useful vcs' that corresponds to my needs... [20:25] mamato_, fastexport + edit + fastimport? [20:25] mamato_, that's not entirely unlike the SVN methodology of dumping to XML to edit history. [20:27] nDuff: I expect there will be a tool to filter a fast-export stream at some point. [20:27] okay... wanting to trim disk usage in a personal-use only project... that's another compelling use-case. ;-) [20:28] (I don't deal with personal-use projects much... except for /etc and ~/ ) === kiko is now known as kiko-afk [20:29] * mamato_ can't find fastexport info on google :S [20:30] * mamato_ found fastimport! [20:30] mamato_, https://lists.ubuntu.com/archives/bazaar/2008q1/038391.html [20:31] mamato_, ...not saying that's the most current location. [20:31] it looks like git already has a tool for filtering fast-export streams: http://www.kernel.org/pub/software/scm/git-core/docs/git-filter-branch.html [20:33] nevans, looks to me like you'd need to actually import the stream into a git repository to use that. Which, granted, wouldn't be the end of the world. [20:35] nevans: thx for the info... [20:38] i hear git is quite nice too... will look into it more closely... except for this, have had good experience with bzr though :( [20:51] how do you .bzrignore some sub-directories? [20:51] mamato_: have you seen http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#ignoring-files ? [20:52] yep [20:52] but didn't find info [20:55] spiv? it only deals with ignoring files... not directories... and specifying directory doesn't seem to work [20:57] mamato_: hmm, I'd expect ingoring a directory to work [20:58] mamato_: it seems to work as I'd expect for me: http://rafb.net/p/nyFWyY31.html [21:01] mamato_: perhaps you've already added the file? "bzr ignore" won't ignore a file that's already versioned. [21:01] I regularly ignore directories. [21:01] mamato_: so you may need to use "bzr rm --keep" on those files. [21:01] damn, i wish i had a spare time machine so i could work on bzr's graph operations [21:01] * spiv -> afk [21:04] weird... your test case works but doesnt work with my branch... and not already versioned... going back to figuring it out... [21:05] ah... parent dir (whihc i want to ignore) IS versionned... makes sense... [21:27] jelmer: I think for the exceptions returning NULL issue you want "cdef int spam() except -1:" (http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/version/Doc/Manual/basics.html#ExceptionValues) [22:07] New bug: #198092 in bzr "Should tell the user to run bzr launchpad-login before push lp:" [High,Triaged] https://launchpad.net/bugs/198092 [22:07] spiv: that doesn't work, since an SVN error is a pointer [22:08] spiv: pyrex only supports "except NULL" but NULL in this case actually is the only return value that means there's no error [22:13] jelmer: got a sec [22:14] ? [22:17] hi AfC [22:20] * AfC waves [22:39] jelmer: don't try to use the same function for two different protocols then :) [22:40] jelmer: the one directly exposed to python _must_ use the python conventions - return NULL -> there is an error set [22:40] jelmer: you probably need to wrap the svn_ra functions with ones that invert the return code to do what you need [22:41] AfC: hi [22:41] lifeless: hi [22:42] I already have one level of indirection - I register a pyrex callback that can calls a python function [22:43] jelmer: I know we almost talked about this the other day, but I was wondering if you have any [further] specific insight into whether or not two different people with different Subversion account names could use a bzr-svn branch once created? [22:44] jelmer: ie, it took me the better part of 9 days to create a bzr-svn branch of GTK. I'd like to share that with someone else to save that being (through no fault of bzr-svn's) someone's first impression of Bazaar [22:44] AfC: you can share that just fine [22:45] AfC: the svn account name is not part of the created bzr branch [22:45] but obviouly they have a different [ssh] account to talk to GNOME's Subversion repository, so if I either a) publish the resultant Bazaar branch, or b) tarball the branch + repository [22:45] and pass it to someone, whether or not it would work [22:45] AfC: Yes, two people with the same name could share a bzr-svn branch [22:45] jelmer: different usernames [22:46] AfC: yes, no problemo [22:46] jelmer: ah. AWESOME [22:46] Then I shall get us hosting a series of such branches as a community service. [22:47] good morning [22:47] jelmer: so I assume all that will have to happen is that when it comes time for them to commit and push back to the upstream Subversion repo is to do [22:48] jelmer: bzr push --remember svn+ssh://their_user_name@svn.gnome.org/svn/gtk+/trunk [22:48] jelmer: and they'll be all set [22:48] AfC: yep [22:48] Beautiful [22:48] AfC: Hopefully shallow branches can help avoid the long time it takes to get an initial branch [22:48] lifeless: What's the status on shallow branches? [22:48] It was interesting to hear Carl report his experience that: [22:49] "The *moment* I see a Subversion URL from someone, even before I think I might want to hack on it, I just feed it to git-svn and let it run on a server, because I know it'll take forever, but eventually it'll be done and I'll have a branch to use from Git if I want to" [22:50] (And they do then share those around, which also gave me the idea of seeing if we could too. Awesome) [22:50] AfC: 9 days seems like a lot of time, btw [22:50] what kind of storage is more resistent to corruption? packs or knits and what kind of storage has better recovery tools? [22:50] I also have a gtk+ trunk import here, and afaik it took less than a day [22:51] (well, I had intermittent network access and a not-svn-HEAD to deal with) [22:51] hsn_: packs [22:51] jelmer: they work but not with the smart server [22:52] jelmer: I'm fixing the root issue preventing them working with the smart server at the moment [22:52] Go-go shallow branches! [22:53] Also go go pyrex bindings [22:53] lifeless: ah, cool [22:58] jelmer: which is the versionedfiles rework [22:58] jelmer: because you need to be able to stack on historical data [22:59] poolie: status for me -> versionedfiles at full steam [23:00] toot toot! [23:00] enjoy [23:08] I just tried to branch a Subversion branch into a pack repo and got this: bzr: ERROR: Repository KnitPackRepository('file:///home/jml/Code/Pimlico/jana/.bzr/repository/') is not compatible with repository SvnRepository('http://svn.o-hand.com/repos/jana') [23:08] I'm using bzr-svn trunk and Bazaar 1.2 [23:09] jml: You need rich-root-pack [23:10] awilkins: that in 1.2? [23:10] jml: Was in .092 AFAIK [23:10] 0.92 [23:11] * jml tries [23:12] OK. Now I'm getting SubversionException: ("PROPFIND request failed on '/repos/jana/branches/jana'", 175002). This is odd, because I can check it out just fine with the svn client [23:13] jml: Is it a password protected repo? [23:13] awilkins: no. [23:13] awilkins: or, at least, it's not protected for reading. [23:13] Are you using a release or the tip of a branch (of bzr-svn) [23:14] awilkins: tip of http://bazaar.launchpad.net/~jelmer/bzr-svn/trunk/ [23:15] I've never used that..... try the 0.4.8 branch [23:16] I presume you've installed patched bindings, etc? [23:17] I'm fairly sure I have. [23:18] maybe I'll try the packaged version. [23:18] bzr-svn will give you a warning if you're not using the patched bindings [23:38] jelmer: so, any ideas? [23:38] jml: whats a jana? [23:39] jml: have you tried the 0.4.8 branch? [23:39] jelmer: no, I'll have a look at that. [23:39] lifeless: it's apparently a japanese word. the project is the openedhand guys' new calendar thingummy [23:40] * awilkins thinks of Jana of the Jungle === kiko-afk is now known as kiko [23:55] fingers crossed, step 1 may be done. whew. [23:59] lifeless: call me sometime today, at your convenience