[00:00] that would be about right [00:00] raw index reads - dictionary compressed [00:00] get_parents as is in .dev - no compression at all [00:00] I bet slapping a gzip around it and doing 64K of compressed data will more than compensate [00:01] also we could add a sliding window [00:01] 64K first response [00:01] 128K second response [00:01] 192K third response [00:02] another possibility is history shortcuts causing existing revisions to be retransmitted [00:02] but I'm not at all sure about a good way to avoid that without excessive server work (have to read the entire search from scratch each time, to generate the seen-and-do-not-transmit-list) [00:03] instrumenting the client to report on duplicate revision receipt with -Dhpss would be a good way to analyse this [00:07] * spiv tries [00:10] lifeless: wow, yes, lots of retransmitted revisions. [00:10] right [00:10] I'll get this patch finished, which will give infrastructure for handling this cleanly [00:11] the other two things are still good things to do [00:11] whats happening is that the path (say) 5 deep along mainline gets us deep history slowly [00:11] but the path 5 deep along long lived but rarely committed to branches takes us deep very quickly [00:12] so that the first request gets us two different pointers in the mainline [00:12] and the server doesn't know when the slower pointer advances up to where the faster pointer jumped to; so it does not filter out the results. [00:12] lifeless: http://rafb.net/p/dv4ApB92.html [00:13] the client knows, so it only asks for what it does not have, but when the server expands the results, this occurs. [00:13] lifeless: so by the looks more than half the data is wasted. [00:13] spiv: thats ok, all the duplicates will be in data we're sending to counteract round trips [00:14] spiv: so its not a huge failure; just expected [00:14] Right, but at the expensive of other data we could be sending to counteract round trips :) [00:14] s/expensive/expense/ [00:14] spiv: no [00:14] spiv: thats where you are wrong; the server could choose not to send this data, but its not at the expense of the data needed to walk :) [00:15] possibly we could sensible advance past those pointers to choose up to 64K of additional data [00:15] lifeless: I meant in an impossibly optimal world, the server would know what the client has already seen [00:15] * spiv blinks [00:15] 150.440 retransmitted revisions: 0 of 0 [00:15] I guess those must be ghosts. [00:16] so I think the biggest immediate problem is the lack of gzip on the content [00:16] * spiv nods [00:18] that will increase the payload of 64K to == or > than packs achieve [00:18] which will reduce the maximum iterations to traverse all history [00:19] and thus the amount of retransmits too [00:19] lifeless, do you remember the url of your progress bar branch? [00:19] if you don't offhand it's not a big deal [00:21] New bug: #183380 in bzr "init-repo using hpss on remote host should use format remote host understands" [Undecided,New] https://launchpad.net/bugs/183380 [00:23] revno 3034 is pushing now to http://people.ubuntu.com/~robertc/baz2.0/nested-pb [00:23] poolie: ^ [00:24] thanxs [00:24] lifeless: FWIW, in 111 get_parent_map calls, 38427 of 53606 items received were already transmitted. [00:26] spiv: thanks [00:27] lifeless, heh, looms :) [00:28] foom, I added a summary of the release to the front page [00:28] * igc dentist appointment - bbl [01:30] New bug: #183391 in bzr "setup.py should have project metadata" [High,Confirmed] https://launchpad.net/bugs/183391 [01:46] poolie: ping [01:47] pong iddle i po [01:47] I'd like a teddy bear that asks questions [01:47] urgently? [01:47] yeah, I think [01:47] ok [01:47] call [02:00] thanks [02:14] poolie: I don't understand your comment in bzrlib.tests.interrepository_implementations.test_interrepository.TestInterRepository.test_interrepository_get_returns_correct_optimiser === jamesh_ is now known as jamesh === `6og is now known as Kamping_Kaiser [02:43] lifeless, the point of the comment is that the relation is not necessarily two-way [02:43] IR1 may wish to be tested with Rx, Ry [02:43] but that does not guarantee that IR1 is the preferred interrepo for Rx,Ry [02:44] so with that disabled the tests for IR1 may not execute [02:45] as the tests are all written on the assumption that it is the preferred interrepo [02:45] as the interrepo paramerisation chooses the Rx and Ry, we can guarantee that IR1 is the preferred interrepo for that combination if we wish [02:45] well [02:46] as i recall, i disabled that test because there were some repos that were not parameterized correctly [02:46] and therefore appeared to be being tested,but they actually were not [02:47] I'll look at it later; I think it explains some of the problems I encountered with the journalled inventory stuff [02:48] it does seem like it'd be useful to reenable it and see whether it fails, or at least what class causes it to fail [02:58] abentley: hi, I was about to send a bug/error report regarding bundlebuggy. [02:58] it's throwing a KeyError when I try to do a search [03:00] http://rafb.net/p/VYvot846.html [03:10] poolie: how is 1.1 more efficient than 1.0 in storage? [03:26] igc, better ordering when packing [03:26] that was my summary of one of the improvements [03:26] Verterok: Okay, thanks. [03:27] poolie, lifeless: I thought that just made log faster? Does it reduce storage as well? [03:28] i meant efficient in time, i guess... [03:28] maybe it implies space, and i don't think that has changed [03:28] What were you searching for? [03:28] abentley: np, I tried to debug it locally, but no TG, etc installed in my laptop [03:29] poolie: cool. Just the wording "efficient storage" on the Welcome page confused me [03:29] feel free to edit [03:30] shall do :-) [03:30] abentley: my email: guillo.gonzo, to check if and old merge request is still there [03:31] Okay, so the issue is that Bundle Buggy contains some merge directives with an invalid format string. [03:32] And when it's parsing those merge directives, the whole thing breaks. [03:32] ok, out for a bit [03:33] ok, so it's only need a cleanup. (great it's not a bug :D ) [03:38] well it is a bug I think; because people may send bad directives anytime [03:38] so it needs to either ignore them on input, or filter them later [03:43] I assumed the old directive isn't a recently submitted one, but you right [03:54] lifeless: (I asked the other day about packs and bzr://, but I assume that if I switch both server and client+ repositories & branches to the new format it at least wont hurt, right?) [03:56] lifeless: I agree it's a bug. I can patch around it in BB, but really bzrlib should never raise KeyErrors. [03:59] abentley: I think letting KeyError though sometimes is ok [03:59] abentley: but yeah BzrError stuff is usually nicer to work with [03:59] "Never" may be a bit strong, but I think it should be, pardon the pun, "the exception". [04:00] :) [04:01] Our public APIs are generally higher-level than that. [04:02] I think deliberately exposing KeyError is ugly, but I think trying to catch every possible underlying error is a timewaste [04:21] Sure. I just think that cases where you can get KeyError are pretty obvious, and if you're surprised by them, it's probably programming error. [04:29] I'm currently using bzr-svn to avoid SVN. However, if I want to get a patch which looks like the one SVN would generate (to send upstream), what should I do? [04:31] bzr diff --old svn://thing [04:31] ? [04:32] I'm packing it in today; I'm a little under the weather (trying to avoid catching the lurgy Lynne has had for a bit( [04:32] [not to mention I started early ;)) [04:32] No '--old' option, apparently. [04:33] diff svn:// . [04:33] then [04:33] because you have bzr < 1.0 [04:33] Thanks. :) [04:33] You may now go off-duty. ;) [04:39] abentley: is lca going to become the default merge algorithm? [04:40] I would like that. [04:40] I'm thinking we should switch it early in a cycle to maximise testing [04:40] I'm already aware of at least one bug. [04:41] And it can't actually be LCA merge, because there are a few cases that LCA merge doesn't handle. [04:41] ah - ok [04:42] So it needs to be "AutoSelectMerge", which would generally select LCA. [04:42] understood [04:42] So it's not just flipping a switch. [04:43] But maybe I should get hacking on AutoSelectMerge. [04:43] abentley: lca sounds pretty sweet to me [04:43] just wanted to make sure we got more people benefiting from it by default [04:44] once it is fully ready that is [04:44] It is pretty nice, and I'm using it as my default. [04:44] via an alias? [04:45] Yeah. [04:45] I think it's the best in its class for handling criss-cross. [04:46] But there are other classes of history-based mergers that may handle certain cases better. [04:46] They are quite expensive for us to use, though. [04:47] And they rely on data that's typically hidden from the user, so where they go wrong, they're completely impenetrable. [04:48] abentley: sounds like the basis for a conference talk later this year say :-) [04:48] Sure, that would be fun. [05:40] [Sorry for asking a question then dropping off; had an X crasher here] [05:59] is there any way to tell bazaar to exclude certain files/directories when doing a "bzr export" ? [06:01] What does the (native) prefix on each line on `bzr help formats` mean? [06:02] pattern: not that I've noticed. Technique we've used quite successfully across darcs, git, and now bzr is to do the export and then to trim the stuff that's unwanted and then create the tarball from there (... all in the `make dist` target) [06:03] pattern: [among other things, getting the name of the top directory being tarred up corresponding to the standard release version number pattern] [06:04] pattern: [for example, the dist target in http://research.operationaldynamics.com/bzr/java-gnome/mainline/Makefile (third target up from the bottom)] [06:04] pattern: [though yesterday I learnt there was a slicker way to determine the no changes state] [06:06] AfC: I believe (native) signifies that the format is not from a plugin. [06:06] spiv: that was my guess. [06:06] AfC: in my bzr install, subversion isn't native, and the rest are. [06:06] Which is right; only the subversion format in that list is from a plugin. [06:06] thanks, AfC [06:23] nice makefile you got there :) [06:23] AfC, tell me one thing... how do you populate that $(VERSION) in your makefile? [06:24] do you get if from bazaar? or do you set it by hand? [06:31] pattern: our top level ./configure extracts it with a regex from a file called src/bindings/org/gnome/gtk/Version.java - it's a constant in the sources [06:32] which we then [06:32] write to an intermediate file. [06:32] Back up: [06:32] (context): [06:32] So my approach to the configuration problem (called "Equivalence", ie, it's equivalent to configure) is a few steps: [06:33] [and note that this is a Java specific discussion; Java is a funny beast and has specific requirements and opportunities] [06:34] A. In Java, you only need to to 3 things: 1. Locate prerequisite libraries and form a CLASSPATH env variable | -classpath VM argument. [06:34] 2. locate and qualify [test] Java compilers and then choose one [06:34] 3. locate and qualify [test] Java runtimes and then choose one [06:35] (that may be installed; I'm a Free Java hacker and I play in the Classpath community, so switching between runtimes to test compatibility etc is a big deal for me; note that most people just think in terms of "is Java installed" [06:36] how does the version constant get in to the source? [06:36] but given the lack of redistributability of Sun's Java for so so long (until about 18 months ago, only 6 months before Sun switched to announcing that Java 7 will be open source) [06:36] pattern: manually [06:36] pattern: that's the origin of the data [06:37] (ie, not data in configure.ac being pumped into a source file) [06:37] even people with Java installed often have it in some wacky place. Total nightmare. Getting better, but still) [06:37] ok [06:38] B. If you know what operating system you're on, you know *exactly* where to look for things. Debian policy says gtk.h is in exactly this spot. Fedora packages put their .jar files in exactly that directory. Etc. [06:39] So, figure out the OS, then probe specific locations. And if not found, you can tell the user exactly what package to install in order to to do something about it. [06:39] Anyway. That all takes place in what is (at present) a Perl file [06:39] [gotta hate prototypes. They never die. This is a > 1800 line Perl script. YEEETCH [06:40] totally not normalized, been meaning to refactor it for now 4+ years, etc [06:40] as it happens, at this point, I intend to fold this experience into Robert's fabricate. So this whole discussion is somewhat academic. But I will now answer your question] [06:41] I used to use Make entirely for the actual build. [06:41] (as it turns out, after ~20 years of happily and successfully using Make I hit, in the space of single week, two show stopping limitations. But anyway) [06:42] So what the top level ./configure spits out is [06:42] a Makefile fragment [06:42] [which we stash in .config] [06:42] with nothing but the variable definitions [06:43] the Makefile then simply does [06:43] -include .config [06:43] ah, i see [06:43] and ta-da is fully configured and instructed with options paths and variables [06:43] (anyway, the fact that the actual build is now a Python script is irrelevant - it sources the same data) [06:43] so to answer your question, [06:44] ./configure grabs the version number out that source file, and then puts it in a line like [06:44] VERSION=4.0.5 [06:44] in .config [06:44] which is then available to the `make dist` target. [06:44] That's it [06:44] right [06:44] makes sense [06:44] thanks for taking the time to explain that to me, afc [06:46] Thanks. It's been a powerful design. I'm rather bitter I haven't had the time to refactor it. I have some pretty nice ideas about syntax for expressing prerequisite data and configurations, (after all, I come from the Infrastructure Management world) but doing domain specific language parsers is sorta beyond my programming skill set at the moment. [06:47] I'm hoping that I'll be able to plug some of the conceptual aspects into lifeless's build system as it comes to fruition. Having had to write even an ad-hoc build engine I know how complex that work is - but how awesome it will be finally have something that's going to get it right. [06:49] sounds like you're on the right track === AnMaster_ is now known as AnMaster [07:50] * igc dinner === asak_ is now known as asak [10:56] bug 164288 [10:56] Launchpad bug 164288 in bzr "bzr serve leaves connections in CLOSE_WAIT a *long* time" [Medium,Confirmed] https://launchpad.net/bugs/164288 [10:56] It's worse than I thought. [11:09] It usually is. [11:14] heh [11:55] AfC: great blog post about open source === asac_ is now known as asac === doko_ is now known as doko [12:41] spiv: thanks mate [13:00] New bug: #183504 in bzr "'bzr status' crash if .bzrignore containts Latin-2 chars" [Undecided,New] https://launchpad.net/bugs/183504 === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell [14:38] ubotu: paste [14:38] pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic) [15:29] Hmm, I currently have my bzr-svn branch checked out at the root (i.e. with trunk, branches, tags). Is there a way I can transfer the changes I've made to a new checkout of just 'trunk' without losing history? [15:30] Odd_Bloke: No [15:30] sorry [15:30] jelmer: Not your fault, I suck. :) [15:31] New bug: #183539 in bzr-log-rss "Malformed XML" [Undecided,New] https://launchpad.net/bugs/183539 [15:31] I'm just going to end up submitting a single patch upstream anyways. :p [15:41] jelmer: I've just got http://paste.pocoo.org/show/21677/ . Any idea what I'm doing wrong? [15:41] yes, the version of bzr-svn you're using is too old for the version of bzr [15:42] Oh wait, I put the new one in the wrong place. ¬.¬ [15:43] There we go. [15:43] All is well with the world. [15:44] jelmer: Thanks. :) [16:04] Am I right in thinking that a branch of an SVN repo is resumable? [16:06] Odd_Bloke: only if it's being run inside a shared repository [16:07] \o/ [16:07] I did it right! :D [16:07] jelmer: Thanks again. [16:24] Anyone know if the Windows version of Bzr is supposed to handle gracefully the problem of having file name case change at random? I'm working with an app that has the annoying habit of saving files with semi-random case for characters in the file extension. This generated a conflict on a pull while ago. [16:35] New bug: #183559 in bzr "bzr switch should have a -r option" [Undecided,New] https://launchpad.net/bugs/183559 [16:46] is there a way to make bzr-svn not push a bunch of commits but instead just one, final commit? [16:46] i.e. when I have made a lot of small changes ('cause that's my style), and then push it back to the svn server, bzr-svn commits each commit I made instead of just bringing the svn server up to the current version in one single commit. [16:47] commit to a feature branch, merge to trunk when it's ready, push to svn only from trunk [16:48] "feature branch" is what? [16:48] bzr branch trunk foo [16:48] one I'm actively developing [16:48] right [16:48] a branch dedicated to a feature [16:48] sounds complicated, but it's better than the insanity of keeping bzr and svn from stomping on each other in the same directory [16:50] I am routinely amazed by the number of people on the Subversion mailing list who can't operate a mail client. [16:51] luks: so I geuss the answer is "no"; I'll have to maintain my own separate repo if I want to stay sane. [16:51] rjek: I'd like to think I would be, but I think the N other mailing lists I follow have inured me to being amazed by such :p [16:51] branch, not repository [16:51] luks: what is difference? [16:51] Solarion: it would be possible to provide a plugin that automates what luks describes [16:52] jelmer: I'd rather just not commit each commit [16:52] Solarion: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#branch [16:52] Solarion: then don't commit each commit :) [16:52] Commit to not commiting each commit? [16:52] luks: I thought committing small changes was good [16:52] fullermd: I suppose so. I like to still have some hope for the human race. [16:53] luks: ah, thanks for the link [16:53] Solarion: combining those commits would mean changing them [16:53] Solarion, that breaks the basic model of bzr-svn [16:53] rjeck: Hope for... dude. Myspace exists. It's too late to hope. [16:53] Why would you not want all the smaller individual changes pushed to the upstream subversion? [16:53] jelmer: but it sounds like the commits are already combined when merging into another bzr branch [16:53] fullermd: You make a depressing but good point. [16:54] ie, why would you want to lose history? [16:54] The thing to hope for now is "Maybe the asteroid will hit closer to them than me, so I can enjoy their demise before embracing mine ;) [16:54] :) [16:55] rjek: apparently my boss wants each individual commit to build, not just HEAD [16:55] I don't want to guarantee that each commit will build; I want to keep a finer-grained history [16:55] only make sure that what I push to svn actually builds [16:55] Solarion: You have to commit a merge - that creates a new commit [16:56] merging branches to trunk is really the best solution for this [16:56] Solarion: "bzr push" is meant to just propagate changes, not change them in any way [16:56] Solarion: furthermore, if you combined revisions, you would have to have push change your local branch [16:56] so I'm just failing to use the tool properly. :) [16:57] Solarion: just have two branches, "trunk" and "work" [16:57] commit small changes to work [16:57] and then you are ready, merge to trunk, push to svn [16:57] Solarion: The usual way of doing that is to push to a branch in svn, and then merge that branch. [16:57] (that's if you don't want to deal with feature branches) [16:58] but I'm already maintaining a feature branch, my local copy. [16:58] then you need also a mirror of svn trunk [16:58] luks: why do I need a mirror? [16:59] If you're just using bzr as a method of doing disconnected subversion, and you want your branches pushed as one big change, svk may be a better solution. [16:59] to merge your feature branch to it [16:59] rjek: I'm using bzr as a method of staying sane. :) [16:59] * rjek wonders if you can do some evil by having an svn checkout also be a bzr branch :) [16:59] add .bzr to the svn ignore list. :) [16:59] rjek: I've done that. It kinda sucks. [16:59] I'm not surprised. [17:00] the suckage is maintainable when you just have a copy on your workstaion, but keeping workstation and notebook in sync gives you the full suckage [17:01] Keep a checkout of svn to one side, and then get bzr to give you a patch that you apply to the svn checkout? [17:01] Personally, I'd push to a branch on the svn server, and then merge to trunk: that way revisions on the trunk always build and you don't lose history. [17:06] rjek: what do you mean precisely? [17:07] 3 branches: svn repo, bzr trunk, bzr feature. Merge between repo and trunk to maintain sync, push/pull between feature and trunk? [17:15] Other way around, I'd think. [17:16] there was a command, at least back in the 0.11 version, that would show me the size of my repository in KB and so on, has it been removed? [17:16] merge between feature and trunk; push/pull between trunk and svn? [17:17] Yeah. Or better, automate the second part by making the trunk a checkout of the svn tree. [17:17] Then you can just 'update ; merge ../feature ; commit' to bring stuff in. [17:23] I need trunk to be centralized === brilliantnu1 is now known as brilliantnut [18:40] Solarion: by "centralized", you mean you want it to be located on a central server? [18:42] abentley: yeah [18:42] I think I've figured out a good system [18:43] plus, whenever it is I leave, my bzr branch can migrate with me without any loss of history or increase in annoyance [18:44] Solarion: you know about checkouts, right? === brilliantnu1 is now known as brilliantnut === bigdo1 is now known as bigdog [19:16] abentley: "know about" in what sense? [19:17] That they allow you to keep your branch in one place and your working directory somewhere else. [19:17] "they" who? [19:18] checkouts [19:18] you mean checkouts from svn [19:18] I mean Bazaar checkouts [19:18] there's no such thing as a bzr checkout [19:19] I use them daily and was involved in their implementation. [19:20] lucky: bzr info -v [19:20] See "bzr help checkouts" [19:20] my impression is that the two branches are on equal footing, aside from policy decisions [19:20] lucky: giving the size needed a bit of time, so it was moved from `bzr info` to `bzr info -v` [19:21] Solarion: I'm not talking about branches, I'm talking about checkouts. [19:22] Branches, are indeed equal. [19:22] abentley: ah, I wasn't aware of this then [19:25] If you want to maintain a branch on a central server, checkouts are a useful tool for that. [19:26] indeedy [19:30] I'm going to have to pull an earlier revision of something from an svn that happened before a certain date which I can easily find by doing bzr log [19:30] * Solarion reads up on checkouts [19:31] now I've tried this before, and I remember it's not just the revision number I need to get that from svn [19:31] but forgot what... I was hoping someone can tell me what I'm supposed to be looking for? [19:34] dato: ah, okay, thank you [19:34] dato: thats what i was looking for [19:34] lucky: you're welcome [19:36] dato: any chance you can sponsor an upload of bzr-pqm? [19:36] jelmer: yeah, send me a mail with the dsc url, and I can do it tomorrow [19:36] like, I think I need a revision ID, but I can't seem to find a parameter for bzr log in the man pages that would also show me the reivision id [19:36] hendrixski: --show-ids? [19:37] dato: Cool, thanks [19:37] dato, that did it [19:39] alrighty, now let's use that revid to pull from svn :-p [19:39] * hendrixski crosses fingers [19:42] abentley: interesting thing === cprov is now known as cprov-out [20:42] So anyone in here using bzr-svn on OS X Leopard ? :D I can't get it to work. [20:42] Bah, I want to put over 100MB of test case data into version control. That's not going to be comfortable. [20:43] well, with svn it's no problem. dunno about bzr. :) [20:43] In svn, I'd just bung it in with the source, and choose not to check it out when I'm at the wrong end of a wet string. [20:44] But that's not really an option in bzr. [20:44] Put it in its own branch? [20:44] I could do. [20:44] It's a result of different world views. bzr has revisions. Within a revision, there are files [20:44] But it kinda breaks my neat hierachy. :) [20:44] CVS/SVN have files. Within files there are revisions [20:44] These are very basic and different ways to look at the world; one can't easily fit the other [20:45] Indeed. [20:45] svn stores files within revisions. [20:45] Not really.. SVN is a versioned filesystem [20:45] it's just that it lets you mix and match in your working directory [20:45] the repository structure is completely revision-based [20:46] * rjek nods. [20:46] It's a versioned filesystem, where a commit on a directory atomically references all files witihn it [20:48] dysinger: I know some folk have [20:50] lifeless: I have been dying to get off of git-svn if you could direct me it would be awesome. I have been banging my head with svn and patches on leopard with no luck. Leopard comes with SVN/Python and SVN/Python SWIG pre-installed and prefers it's own install over /usr/local [20:52] dysinger: you can probably control that with PYTHONPATH, which prepends to the path python looks for such libraries [20:52] dysinger: why dying to get off of git-svn? [20:52] foom: to use bzr ? :) [20:52] lifeless: obviously, but I thought maybe there was a reason. :) [20:52] Yeah I don't mind git-svn so much as the rest of my team wouldn't use it because of the learning curve. [20:52] bzr is easier to wrap your mind around. [20:52] why did the chicken cross the road? [20:53] so i could eat it [20:53] and you don't have to do things like git push dev :refs/head/my-branch [20:53] and other BS [20:53] i mean, I have a reason why I don't want to use git-svn: it doesn't seem to store enough data in svn to allow cross merging with other git-svn users and pulling the same changes from svn to work [20:54] I cross merge with other git-svn users [20:54] last time I tried it was 6 months ago or so I think [20:54] But it's a PITA - basically it means pull and pushing to SVN & also pulling and pushing to a server with a clone of your git-svn [20:54] so you can share your local branches with someone else [20:55] git is way to complex for the average user IMO [20:55] dysinger: I have noticed you popping in and out on IRC... if I can make a suggestion; open a 'question' on bzr-svn - https://answers.launchpad.net/bzr-svn [20:55] I could only sway my top dev to try it with me. Everyone else on the team is lost with Git. [20:55] yes, it really does have a poor UI. [20:55] dysinger: this is a support forum, and will mean you don't have to be online at the same time as the bzr-svn developer[s] [20:55] i'm sure it makes sense if you're linus. other than that, no, not really. :P [20:56] lifeless: sure. [20:56] thanks - I just am used to using IRC [20:56] IRC is great but it can be lossy; and this is dragging on for you :) [20:57] I already spoke to the bzr-svn maintainer about it a couple weeks back with no luck. [20:57] I'll just keep using bzr for private projects for now. [20:57] you could do the bzr-svn bit on a different machine. :) [20:58] 'evening folks [20:59] Jeez, didn't even have to say his name that time... [21:11] I added the OS X Leopard bzr-svn to questions at launchpad. Hopefully I can help and we can get to the bottom of the problem so that all OS X users can use it. DVCS is only useful to a lot of people if they can still interact with SVN. [21:11] https://answers.launchpad.net/bzr-svn/+question/22326 [21:14] dysinger: You may also have to run 'make install' [21:14] That's right there in the script [21:14] ... [21:14] make check [21:14] sudo make install [21:14] make swig-py [21:14] make check-swig-py [21:15] It puts everything in the right place [21:15] and [21:15] # Check it --- [21:15] python -c "import svn.delta; print svn.delta.__file__" [21:15] finds the right python script [21:15] but python -c "from svn.delta import svn_delta_invoke_txdelta_window_handler" doesn't work [21:16] what does the following print [21:16] python -c "import svn.delta; print svn.delta.__file__" [21:17] also, is LD_LIBRARY_PATH portable to Mac OS X? [21:17] it looks like that should be DYLD_LIBRARY_PATH [21:17] OK I'll try that [21:18] one sec === bigdo2 is now known as bigdog [21:34] ok sorry I got distracted on work. Before patching svn I get /System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/svn/delta.pyc as expect for python -c "import svn.delta; print svn.delta.__file__" ... [21:35] After I got /usr/local/lib/svn-python/svn/delta.pyc [21:35] and it still doesn't work? [21:35] no [21:36] I tried both LD_LIB... and DYLD_LIBRARY_PATH [21:36] set to /usr/local [21:36] python -c "import svn.delta; print svn.delta.__file__" [21:36] Duece:subversion-1.4.6 tim$ [21:36]