[00:08] jelmer: what is 'discovering revisions' in a bzr-svn branch operation [00:08] jelmer: after the tip of the output branch is set [00:18] jelmer: hey, push is still broken :/ [00:19] pushing to an existing branch emits "Created new branch." no matter what [00:20] And --remember seems to be ineffective [00:27] Filed: https://bugs.launchpad.net/bzr-svn/+bug/355914 [00:27] Launchpad bug 355914 in bzr-svn "bzr push always reports that it created a new branch and --remember is ineffective" [Undecided,New] [00:31] morning [00:36] hi igc [00:37] jml: python commit - 71208 ;) [00:37] small steps [00:40] hi lifeless, jml [00:41] igc: hello [01:12] hi, I have a possible bug, and I am wondering if anyone wants to help me :) [01:13] probably, but just ask [01:14] it seems to be similar to a lot of other bugs, especially #295611 [01:14] I try and do a bzr upgrade --1.9, and it fails with that NoSuchRevision exception. [01:14] I am using bzr-1.13 [01:14] what does 'bzr info -v' report? [01:14] bzr info -v [01:14] Format: [01:14] control: Meta directory format 1 [01:14] branch: Branch format 5 [01:14] repository: Packs containing knits without subtree support [01:15] does 'bzr check' succeed? [01:16] um. [01:16] not sure. [01:16] Good answer [01:16] We could be here for a while. [01:16] 31219 revisions. [01:16] running [01:17] I *thought* I ran it before and it didn't return any errors. [01:17] I imagine this could take a few hours [01:18] Should I come back when it is finished? [01:20] jelmer: push reports that there are no revisions to pull now :p [01:24] kingos: please [01:24] kingos: you're welcome to remain here in the interim of course :) [01:30] I'm trying to clone http://bzr.notengoamigos.org/emacs/trunk/ but bzr ate all my memory [01:30] It hasn't written a single byte into the pack file yet [01:31] anything I can do besides more memory? [01:31] using 506MB RSS [01:33] ivan: emacs is very big; we're bringing in a bunch of changes of the next couple of releases that will help a lot [01:34] cool, I will relax until then [01:34] "bzr ate my memory" ... that's better than "the dog ate my homework" [01:35] ivan: no idea if this will help, but something I had to do when converting things like GTK from svn to bzr was to work in smaller chunks [01:35] (this was due to Subversion's server crashing, not Bazaar's problem) [01:35] by doing [01:35] $ bzr init . [01:35] $ bzr pull -r 100 URL [01:35] $ bzr pull -r 200 URL [01:35] and so on. Yes, I used a loop and expr :) [01:36] ivan: the bulk of that 500MB is probably index handling, that branch is in our default format which is quite memory hungry [01:36] igc: so, more bbc today [01:37] [interestingly, Subversion is horrible at accessing historical revisions; it took over 30 minutes for svn to dig out 100 revisions at first. This dropped to 9 minutes at the end. Unreal] [01:37] lifeless: (maybe we should politely encourage someone there to upgrade it?) [01:37] i've crashed svn servers pulling history [01:38] well, just one :) [01:40] AfC: seems to be working great, thanks [01:40] lifeless: absolutely - on it now [01:40] lifeless: next review will be for the intertree stuff [01:44] igc: what are you waiting on me for [01:44] spiv: ping; want to work together today? [01:45] lifeless: nothing yet. I'm hoping you or poolie are chasing that legal issue though [01:45] poolie is still on leave [01:45] lifeless: back tomorrow then? [01:45] I had assumed it was today [01:47] lifeless: looks like poolie is back Wed [01:48] yes [01:57] 10% through [02:22] spiv: ping [02:22] lifeless: pong [02:23] 10:40 < lifeless> spiv: ping; want to work together today? [02:23] also, do I remember correctly that my set_config_option patch was approved by you? [02:23] lifeless: yes, and BB should remember that for you too ;) [02:25] lifeless: I think I'd rather work by myself today. [02:27] spiv: cool [02:27] spiv: you're working on the critical bug yeah? [02:27] Yeah. [02:27] if you need any assistance shout out [02:28] I think you'll need to patch the code that does seen_parents = ... [02:29] to determine that [some] parents are unavailable and now try to read them etc [02:29] spiv: and I agree, 1.13.2 is a good idea [02:31] * spiv ndos [02:31] nods, even [02:50] * igc food [02:56] lifeless: bzr check fails [02:56] bzr: ERROR: exceptions.KeyError: [02:57] that sounds bad [02:57] kingos: well it means the problem is not related to upgrade [02:57] is this a bzr-svn converted branch? [03:47] lifeless: "discovering revisions" after setting the branch tip means it's determining the revids to use for tags [03:48] lifeless: the InterBranch.pull() branch I submitted pretty much eliminates that [03:50] ok [03:51] Hm. [03:52] So, assume I have two branches with shared history, but one has gone way off in its own direction since they diverged. [03:52] If, in the "older" one, I do a merge --uncommitted, is it going to pull all those revs into its repository before it does its thing in the WT? [03:57] (and/or the same Q with cherrypicks) [03:58] no [03:58] or [03:58] maybe [03:59] Hm. 'k. [03:59] 'cuz I've got this branch that should have (and does have) a completely linear history. It also has [03:59] Branch history: [03:59] Repository: [03:59] 502 revisions [03:59] 28 revisions [03:59] Was trying to figure out how they got crammed in there... [04:00] probably that [04:00] I have done one or the other of --uncommitted and cherrypicks into it, so... [04:00] they won't propogate on push.pull [04:00] Or indeed commit (this being a checkout) [04:01] Which is slightly weird. It suggests that would be another difference in what happens where between light/heavy checkouts :| [04:30] igc: would a phone call about the format names help? [04:33] lifeless: not at this point - I'm about to have lunch and I'm deep in other stuff [04:33] lifeless: I'd also like to hear from others beyond you and I [04:34] * fullermd prefers serial numbering. [04:36] jelmer: ping [04:37] * igc lunch === lamont` is now known as lamont === jamesh_ is now known as jamesh [04:44] lifeless: no, not bzr-svn [04:45] has been around a long long time. [04:46] has had everything done to it at various points in time [04:46] eg. uncommit [04:46] etc. [04:47] kingos: please file a bug, I'll generate a little script to get details about whats going on [04:49] urgh ok [04:49] lost the output [04:49] it may be in ~/.bzr.log [04:50] igc: FWIW, I don't like 1.15-development, but development-1.15 seems okay to me. But I'm still happy with development6. [06:16] Is there a way to stop bzr from adding [merge] when it's giving single line summaries (log, missing, etc) of revisions that just happen to be merges? [06:17] It's quite annoying. If I wanted that text in the commit message I would have added it. [06:19] AfC: not currently. It there to tell users that there's interesting stuff under that revision [06:20] hmmm. bzr check seems to have gotten further than last time. [06:20] I guess we could suppress it if you've given -n0 though [06:21] AfC: And the text isn't in the commit message (it's just shown before it) [06:22] igc: come on, mate. You know what I mean. [06:24] igc: incidentally, this is the second time I've seen you mention this "-n0" thing. What is that? I don't see it on the help of `bzr missing` [06:25] AfC: missing doesn't support it yet - it has --include-merges though (which is the same thing) [06:25] It would be good to suppress it if we're going to show those revisions anyway. That is, if we've asked for the next depth of revisions we don't show [merge]. I also wonder, given that --line is supposed to be quite terse, that another indicator than [merge] (7 characters) might be used. [06:25] AfC: see bzr help log [06:26] Ah [06:26] Well, that's fine and nice for `log`. Not much use for the other commands. [06:26] Anyway, if we could have a global config option to stop bzr adding decorations that we didn't ask for, that'd be great. [06:28] if I want to merge in a branch but only to a specified revno, can I just go "bzr merge ../other-branch -r 1234" ? [06:28] thumper: yes [06:29] spiv: ta [06:29] Don't you want it to be a range of revisions - or it's a cherry pick I thought [06:29] * Talden is a bzr noob - you have been warned... [06:30] Ahh no a range of a single rev is cherry pick... [06:31] Talden: if you give a single revision rather than a range to merge it'll assume you want all the revisions upto and including the specified revision. [06:32] It's only if you specify a range that you can get a cherrypick. (And even then, if you choose a range that is forwards and connected/overlapping your current ancestry then bzr will treat it as a regular merge rather than a cherrypick) [06:33] lifeless: bug filed as #356028 [06:38] lifeless? [06:40] kingos: thanks, I'll put together a small script over the next day or two and get you to run it [06:40] lifeless: thanks. [06:40] lifeless: what are the implications of this? is our repo busted? or will we be able to fix it? [06:41] clearly something is wrong [06:41] the nature of that we have yet to ascertain [06:41] of course. I just thought you may have some ideas what the implications could be [06:41] its probably that any missing content is in someones source branch [06:41] pretty scary! :) [06:42] and once we identify it they - e.g. - tibra.com.au - can do a custom push to fix it up [06:42] I also need to ascertain *why* you have any glitching occuring [06:43] bzr is fairly cautious about copying your history around [06:43] as a just in case, don't delete any old branches you have hanging around, or old repos [06:44] ok [06:44] but normal use on an ongoing basis should be fine [06:44] 'someemail@blah.com20080728 [06:44] so much for privacy ... left an email address in :( [06:44] edit it now, I doubt google will have found it [06:45] there's also a tonne of spaces [06:45] so I doubt spammers will pickup on it [06:45] anyhow, the key its erroring on is roughly when/where something went wrong [06:45] how do I edit it ... can't see an edit button [06:46] foudn it [06:46] thanks for your help lifeless [06:47] np. I'm treating this as serious, but we're juggling time to get 1.14 out, which is why you're not getting the script *today* [06:47] we have a couple of important RC bugs [06:47] spiv: speaking of which... [06:47] how goes it? [07:20] hi all === spm_ is now known as spm [08:05] igc: I'm about to call it a day [08:20] lifeless: ok, I'm off to the hospital tomorrow at 9am for most the day btw [08:21] igc: good luck [08:21] lifeless: thanks [08:21] lifeless: I'm make a bit more progress on integrating bbc tonight but a review of the gc patch would be great tomorrow say [08:22] s/I'm/I'll/ [08:23] other than the licence question I think its landable [08:24] vila: can I ask you to tweak (and land into bzr.dev) the InterCHKRevisionTree code as lifeless and jam requested in their reviews? [08:51] igc: "lifelessjamcompress" is a weird name. Why would you compress jam, and why would you need a different compress for jam that is alive? :D [11:00] jelmer, is bzr git supposed to do clones? [11:01] like this: bzr branch git://github.com/bla/bla.git ? [11:01] every time I try that I get random number at "Compressing objects" step... === LenZGr_ is now known as LenZGr [12:17] alright, my ex-girlfriend wants to write her thesis and I though bazaar would be a good DVCS system for her windows + latex workflow [12:17] any recommendations on a gui for her? === UdontKnow is now known as udk [12:37] herzi: you mean a Microsoft Windows GUI, I assume [12:40] herzi: (and not X Windows) [12:40] herzi: there is http://bazaar-vcs.org/TortoiseBzr [12:40] I have no idea if it's {complete, usable, nice to use, etc}. [12:43] Honestly... not really but it is getting better. [12:46] * AfC vaguely wonders what it is that Microsoft people DO do to work with bzr [12:47] of course, [12:47] * AfC vaguely wonders what it is that Microsoft people DO do to do work [12:49] lifeless: Do you have an opinion on bug #354843 ? [12:49] Launchpad bug 354843 in bzr "Bzr should be smart about who owns ~/.bzr.log" [Undecided,New] https://launchpad.net/bugs/354843 [12:51] herzi: (sorry I couldn't be more help) [12:54] jpds: not really, certainly it would be better to tell the user what is wrong [12:59] AfC - commandline... the odd qbzr command... I'm happy enough at the prompt - getting adoption at work though would require a good GUI or shell integration at the least and probably IDE integration for full buy-in. We have scaling issues first though that brisbane-core looks like it might resolve. [13:00] Talden: perhaps we should suggest Sven investigate QBzr on Windows, then [13:02] AIUI it takes the commandline to invoke the various qbzr dialogs. Some at my workplace seem to have some sort of allergic reaction when commandline use is mentioned (certainly there's a lot of red-faced frothing at the mouth). [13:03] lifeless: Yes, my thoughts exactly. [13:04] * Talden wanders off to bed here in NZ. [13:45] lifeless: pong [13:51] jpds: the immediate issue is that the warning is from an external library, and the library also provides no sensible way to determine if it just gave that error so you could add some explanatory text afterwards [13:54] Hi all [13:54] jelmer: Can one install bzrtools from sid on lenny with the bzr backport? [13:56] Lo-lan-do: hi [13:56] Lo-lan-do: I think so [13:56] at least the versions match, I haven't tested the particular combination [13:58] Blargh [13:58] bzrtools: Depends: python-central (>= 0.6.11) but 0.6.8 is installed. [13:59] Lo-lan-do: Is there anything particular from bzrtools you need? [14:00] Lo-lan-do: shelve and clean-tree were moved into bzr core from bzrtools [14:00] Let's remove it then, see if anybody complains :-) [14:29] james_w: Hi James. Aren't you the guy who created package-import.ubuntu.com? [14:29] Bluehorn: yup [14:30] james_w: I am trying to get a package of mine imported into bzr, and bzr dsc-import does not cut it for me. [14:30] james_w: Is the code for package-import somewhere available? [14:30] it just uses dsc-import under the hood [14:30] Because I like the package-import setup - having a distinct upstream branch etc. [14:31] hmm, okay. how do you get the seperation into package-upstream and package-{hoary/warty/you-name-it}? [14:32] james_w: BTW: Great work. Actually having bzr repos for most ubuntu packages makes it interesting to use bzr for me - so that the exchange Ubuntu<->Debian can go faster. [14:33] ah [14:33] I just create the upstream branch by hand afterwards actually [14:34] Manually, for all packages? Or do you have a script for that? [14:35] yeah, it's part of the driver script [14:36] once you have done dsc-import it's easy to find the tip of the upstream branch via it's tag, and this can be branched/pulled out [14:37] james_w: May I ask if the driver script is available somewhere? ;-) [14:37] it's not currently [14:38] james_w: Would save me some time, I already tried to change dsc-import to support an upstream branch (and to use a shared repo), but I did not dig through the bzr python api fast enough. [14:38] package-import.ubuntu.com seems to have messed up unicode for maintainer names [14:38] luks: do you have an example? [14:38] james_w: okay, thank you anyway. [14:38] james_w: I'll try to reproduce the "pull out upstream" functionality. [14:38] http://package-import.ubuntu.com/libd/libdiscid/hardy/changes [14:38] Bluehorn: thanks for the feedback [14:39] luks: thanks, I'll look in to that [14:39] it's utf8 in debian/changes, seems to be parsed as latin1 [14:39] *changelog [14:41] luks: probably dependent on the current user locale... ;-) [14:41] yeah, not a good solution if you are importing the whole distro === ja1 is now known as jam [16:38] Hi All, I have a problem using Bazaar when sending files using FTP. Apparently my hosts ftp server doesn't support the APPE command. Is there a way around this? === udk is now known as UdontKnow [18:32] how do i change a default parent like doing --rememeber, without actually doing the pull? [18:36] fallenpegasus: can you do something like: `bzr pull -r latest-local-revision --remember /foo/bar` ‽ [18:37] fallenpegasus: you can edit .bzr/branch/branch.conf [18:41] thanks! [19:00] Is there a delay from when you push to LP to when PQM can access it? [19:06] BasicOSX: yeah [19:07] BasicOSX: you can test that by accessing it via http === beuno_ is now known as beuno [19:29] ok, that explains why I push to lp, the pqm submit and pqm yells at me with a "non-PQM managed branch" === beuno_ is now known as beuno [20:10] hello all, someone send a diff to me via email starting "# Bazaar merge directive format 2 (Bazaar 0.90)" ... . What do I have to do now? [20:11] theAdib: "bzr merge " [20:12] theAdib: or "bzr pull " [20:13] theAdib: assuming you are using bzr [20:13] hey jelmer! [20:14] cool: bzr pull foo.patch worked thanks [20:14] theAdib: good :) [20:14] theAdib: generated by `bzr send` btw [20:16] would putting a sentence in the header make sense? [20:17] either a pointer to a help topic, or "you can use bzr merge " or something? [20:19] PQM failures are back for me, nothing different from the last time I submitted. Error here: http://www.nopaste.com/p/aLsVQmm8v [20:26] james_w: yeah, I think so [20:27] LarstiQ: dude! [20:27] jelmer: I'm not dead yet! [20:35] LarstiQ: how are things? [20:35] vila: pingz0rz [20:37] BasicOSX: replace your lp url by an http one (I had troubles with PQM and lp urls, different than yours, but worth a try) [20:37] jelmer: pong [20:37] jelmer: Anu came to visit from 26th of march till 3 april [20:38] jelmer: back to long working hours now [20:41] vila: a colleague of mine has (recently) done some work to build on httplib (and urllib2 a bit iirc) to make it do things we need, more than just GET [20:41] vila: ie PUT, 100-continue, and I forget more [20:41] vila: I was wondering if you had any more feedback on my username patch :-) [20:42] vila: would you be interested in discussing with him possibly joining forces? Since Bazaar beefs up stdlib in that area as well. [20:42] * LarstiQ would ideally want to upstream it all the way to Python, but maybe a good library on top of it is more feasible [20:44] jelmer: no time today, but roughly, except for maybe a s/password/user/ it sounded good, I hope to review it tomorrow [20:44] LarstiQ: Ahh, that explains your sudden quietness on IRC (-: [20:45] LarstiQ: certainly [20:45] vila: Cool, thanks :-) [20:46] the urllib based implementation shows its limits, replacing it by an enhanced httplib is the way to go (urllib2 is targeted at *downloading* *one* url, not the fundation I will chose today if I was starting again) [20:46] Ooooh the new 'bzr shelve' is now in my debian/testing desktop... [20:46] Finally [20:46] LarstiQ: httplib is more oriented to connection handling like we need [20:47] LarstiQ: but bzr-webdav already has PUT and some more :-) (It even had 100-continue at one point :) [20:48] LeoNerd: yeah, the new shelve is really neat [20:48] It's cute... it can .. like.. actually cope with pending-add and pending-delete now [20:48] And it doesn't litter .shelf about the place [20:49] LeoNerd: it can even shelve renames :-) [20:49] Oh.. the old shelve could do that [20:50] oh, ok, I wasn't aware of that [20:53] vila: cool, should I just give him your email address, or is there a more suitable forum to discuss things? === cprov is now known as cprov-afk [20:55] LarstiQ: here, email, bazaar ML all are fine I think, 100-continue will be welcome in bzr and landing webdav in core is on the agenda, so... [20:56] vila: k [20:56] Tak: hi [20:58] jelmer: hey, what's up? [20:58] Tak: Looks like I can finally build monodevelop-bzr \o/ [20:58] hooray! [21:02] * Tak brace for critique [21:05] Tak: I'm not getting it to load yet [21:05] Tak: I've also fixed some things in my branch to get it to build [21:06] Tak: System.InvalidOperationException: Type 'MonoDevelop.VersionControl.Bazaar.BazaarCommands' not found in add-in 'MonoDevelop.VersionControl.Bazaar,1.9.3' [21:07] BasicOSX: Once my patch land, you may want to edit the NEWS file, I wasn't clear about where to put the fix for #355273 [21:07] ok [21:07] PQM still eating on it [21:08] jelmer: that's defined in BazaarCommands.cs - is there maybe an old assembly floating around? [21:11] BasicOSX: Eerk, just saw that, I thought your 'Approved' meant: 'Go, sent it to pqm' :-/ [21:12] he [21:12] heh [21:12] Your mailing list said if you would like to merge yourself [21:13] BasicOSX: So, you're still using lp:~tanner/bzr/1.14rc1, you can use http://bazaar.launchpad.net/~tanner/bzr/1.14rc1 [21:13] BasicOSX: *I* had problems with lp urls making PQM hang, but that's me :) [21:14] BasicOSX: yeah, sure, no problem [21:15] I'm off, have a nice day all [21:17] BasicOSX: by the way, I worked a bit on bug #355454, AFAICS, the warning is still harmless, we should avoid it, but the strings *are* different when the warning fired (one path is file, the other is its base dir), so don't worry too much about it) [21:17] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/355454/+text) [21:18] if even ubottu times out now :) [21:18] who's gonna gimme a quick line to migrate git repo to bzr? :) [21:18] (and yes, I know about fast-import) [21:19] Tak: no, that doesn't seem to help [21:19] pygi: bzr git-import ? [21:19] jelmer, o, such a command exists? xD [21:19] pygi: if you have bzr-git installed [21:20] jelmer, yes, I do [21:20] jelmer, I tried doing "bzr branch git://path" but it didn't work :p [21:20] pygi: oh, that should work [21:21] jelmer, hm, this command seems to have same problem...compressing objects stops at random percentage [21:21] pygi: please file a ug [21:21] *bug [21:22] jelmer, bzr: ERROR: mmap.error: [Errno 22] Invalid argument [21:22] oh well [21:22] will do [21:22] pygi: ah, you're running python2.6 ? [21:22] jelmer, yes? [21:23] pygi: there's a bug in the way bzr-git uses the offset argument to mmap apparently [21:23] and that parameter is only available in py2.6 [21:23] jelmer, right, so I should just try calling bzr with py2.5? [21:23] Tak: perhaps I'm installing the plugin differently; I'm building a repository and installing from that [21:23] Tak: is there an easier way? [21:24] I'm building the plugin, then manually dropping the dll into my addins directory [21:24] I guess if it doesn't work to create a repo and install that way, it needs to be addressed, though [21:29] jelmer, want a patch for sha deprecation warning? === Toksyury1l is now known as Toksyuryel [21:31] pygi: where is that occurring? [21:32] jelmer, dulwich if I remember right [21:32] pygi: sure that isn't a pycrypto issue? [21:33] BasicOSX, well, it tells me that sha is deprecated, to use hashlib instead :p [21:34] pygi: Are you using the latest dulwich, I thought we had fixed all those issues.. [21:35] Tak: woot, I got it working now [21:35] jelmer, latest from bzr [21:35] woo! [21:37] vila: just point of interest, if my pqm of your patch played ok, won't your pqm just fall out with nothing to do? I still see your patch playing. [21:37] pygi: in that case, please submit [21:39] jelmer, will do, I'll try to fetch/install once again [22:10] BasicOSX: it will find a merge to do [22:16] lifeless: pong [22:19] hi [22:21] lifeless: you pinged me yesterday? [22:26] *gone* [22:30] [as in the reason is gone] [22:32] lifeless: ah, ok [22:33] * jelmer wonders how much review plugging he can do before it becomes annoying [22:43] jelmer: for your serialiser? [22:52] lifeless: InterBranch.pull in particular, as that will be very noticable to bzr-svn users [22:53] lifeless: I'd already given up on RIOSerializer making it into the new format - am I mistaken? [22:55] yes, it can't get in 1.14, it can in 1.15 [22:55] beta format != no more changes [23:16] lifeless: ok, so I guess that means I have at least another week or to to whine about reviews for that :-) [23:47] hmm, I seem to have a case of bzr pushing a full branch to launchpad again [23:48] Using saved push location: bzr+ssh://james-w@bazaar.launchpad.net/~james-w/bzr/bzr.dev.hooks [23:48] Source format does not support stacking, using format: 'Remote BZR Branch' [23:48] bzr remote repository [23:48] Using default stacking branch /~bzr/bzr/trunk at bzr+ssh://james-w@bazaar.launchpad.net/%7Ejames-w/bzr/ [23:48] then lots of data being sent [23:51] james_w: bzr version? [23:51] revision: 4230 [23:51] hmm, that's a bit old [23:52] lifeless: what is record_entry_contents() used for these days? [23:52] jelmer: commit [23:53] lifeless: as opposed to record_iter_changes, I mean? [23:53] jelmer: we use record_iter_changes when it will be faster [23:54] is there any way I can force either to be used? [23:54] not currently, why? [23:54] still get the same message with the tip of bzr.dev [23:55] james_w: rev 4174 fixed it in theory, if the /~bzr/bzr/trunk is stackable on lp [23:55] Hi folks, I've got a question about doing a bzr push to a svn project that does not yet exist. I'm doing a bzr push --create-prefix [url.../trunk] but bzr complains: ERROR: Prefix missing for branches/merged; please create it before pushing. Both branches and tags projects exist. I am confused; what is wrong here? [23:56] it should be, if it isn't we should certainly fix that [23:56] grettke: which version of bzr-svn? [23:56] james_w: it is [23:56] lifeless: I don't have record_iter_changes implemented for bzr-svn yet [23:57] james_w: so, check your ~/.bzr.log [23:57] nothing interesting [23:58] grettke: if it's not bzr-svn trunk then you need to use "bzr svn-push" rather than "bzr push" [23:58] james_w: if you can reproduce this, get a trace using -Dhpss and file a bug [23:58] [14773] 2009-04-06 23:52:29.421 INFO: Source format does not support stacking, using format: 'Remote BZR Branch' [23:58] bzr remote repository [23:58] [14773] 2009-04-06 23:52:29.427 INFO: Using default stacking branch /~bzr/bzr/trunk at bzr+ssh://james-w@bazaar.launchpad.net/%7Ejames-w/bzr/ [23:58] 11.267 Using fetch logic to copy between KnitPackRepository('file:///home/jw2328/devel/bzr/.bzr/repository/')() and RemoteRepository(bzr+ssh://james-w@bazaar.launchpad.net/%7Ejames-w/bzr/bzr.dev.known_hooks/.bzr/)() [23:58] jelmer: I am using bzr 1.12 (standard install). Where do I check which bzr svn is it? [23:58]