[01:07] root@shard:~# bzr branch lp:lava-deployment-script [01:07] You have not informed bzr of your Launchpad ID, and you must do this to [01:07] write to Launchpad or access private data. See "bzr help launchpad-login". [01:07] bzr: ERROR: Invalid url supplied to transport: "bzr+ssh://bazaar.launchpad.net/+branch/lava-deployment-script": no supported schemes [01:07] is this just me being stupid? [01:07] it seems a little strange [01:16] that looks odd [01:16] i guess that means 'there is no trunk registered' [01:17] there is no project of that name at all [01:17] obviously it's a crappy error message [01:20] mwhudson, you are silly [01:20] mwhudson, s/script/tool/ [01:21] zyga-afk: ah ofc [01:22] poolie: oh right, because lp lookup is unauthenticated, i _might_ be referring to a private project, not one that does not exist [01:22] hnnngh [01:23] maybe i'll do some launchpad hacking tonight... [01:29] back home [01:31] mwhudson: :) === lifeless is now known as subunit === subunit is now known as lifeless [01:45] mwhudson, if you use a sufficiently new bzr it will not be doing a separate lookup [01:45] the fact that it got the +branch url seems to indicate [01:45] that the problem was later on [01:46] poolie: even if there is no username set? [01:46] i thought in that case it did [01:46] (coz +branch urls don't work over http) [01:46] ah you're correct [01:46] :/ [01:47] i have this branch that does anonymous ssh though........... [01:47] (if i do do some hacking tonight, it will be to make that branch check a ff) === zyga-afk is now known as zyga-really-afk [02:22] is staging.launchpad.net no longer updated? what's the current site for breaking stuff without bothering real people? [02:22] staging and or qastaging [02:22] (staging says r11151 and main is r1429) [02:22] they are different branches [02:23] * r14291 [02:23] different mainlines even - they don't get pulled between [02:23] ah, and qastaging is even newer, cool. [02:23] okay, time to test idea quickly [02:51] hi wgz [02:51] lunch time [05:31] How do I do bzr patch on Windows? [05:36] GungaDin :) [05:37] I was wondering if there is a way to see when a certain line in a source file was last changed somehow? [05:37] bzr annotate [05:37] spiv? [05:39] jo-erlend: http://doc.bazaar.canonical.com/bzr.2.4/en/user-reference/annotate-help.html [05:40] And the GUI versions in bzr-gtk/qbzr (bzr gannotate/bzr qannotate) are quite nice. [06:34] spiv, nice! Thank you :) [08:31] I do my main development on my desktop. I push to launchpad. But I also have a laptop where I often do offline work. What's the best way to keep the laptop and desktop in sync? [09:09] jelmer: rough analysis posted for the 'bzr config' proposal: tl;dr: the old code wasn't checking the lock which was a bug [09:40] wgz: tell mgz: \o/ windows slave down to 11 failures ! [09:42] wgz: I'm sure you will love to fix the 3 TestTreeTransform ones :-D [09:48] morning all [09:50] hi all! i and my co-worker want to work on our code using bzr. we don't want to have parent repos, but instead pull commits from each other. what's the best way to do that? [09:51] mgz: \o/ windows slave down to 11 failures ! [09:51] mgz: I'm sure you will love to fix the 3 TestTreeTransform ones :-D [09:52] Sindikat: you will both need to read from each other with whatever protocol you want (ssh is preferred as it also allows writes) [09:53] using 'bzr pull' or 'bzr push'? [09:53] Sindikat: even with only two people, having one 'main' branch then both of you doing changes in feature branches is a reasonable way of working [09:53] vila: cool, I'll have another look [09:53] Sindikat: from there, it's easier if you use a specific branch as the one that is shared between both of you so all your merges will happen there [09:53] vila: yup, getting there [09:54] vila: it's not that distributed then [09:56] Sindikat: it's as distributed as any other workflow ;) It will allow a clearer sharing, but feel free to mirror each other branch if you're more comfortable with that [09:56] i'm just not experienced with VCS :) [09:57] Sindikat: distributed imho mainly matters when it comes to being able to work offline, how source is shared (and how the shared history is handled) is more relevant [09:58] Sindikat: have a look at http://doc.bazaar.canonical.com/bzr.dev/en/tutorials/index.html === zyga is now known as zyga-afk [10:33] hey, launchpad now has a cute(ish) down page [10:39] i went thru tutorials, but smth isn't clear. i've did 'bzr init-repo project', in which i did 'bzr init trunk' on some server. now i want to download this trunk branch from server to my local computer. what should i do? [10:47] Sindikat: once you've committed something to trunk, you just do `bzr branch .../server/path .../local/path` [10:47] mgz: thanks! i'm currently going thru the guide, so i think i'll find out how to use bzr ;) [10:49] how are you accessing the server currently? [10:50] you want ssh set up for both of you for write access ideally. [10:50] ssh [10:50] cool. [10:50] mgz: currently i already have a branch on server, but don't know how to get pushing to server working [10:57] mgz: hehe, yeah seen it, liked it :) [10:57] Sindikat: once you have a repo like you can access via bzr+ssh://host/path/to/branch you pass that to any commands [10:58] and bzr will remember the push and pull locations, so you can easily have a local mirror [11:32] why is there a module-locale dict of handles in bzrlib.transport... [11:33] vila: so, the bad news is all but the two already reported windows failures are basically random (but likely) races involving sftp [11:33] the good news is I can actually repo them here from time to time [11:34] oh, and the bt.test_transform ones are just exception stringifying [11:35] but eg. bb.test_branch.TestRemoteBranch.test_branch_remote_remote was failing from time to time even before the big location handling regression [11:35] <- moment of boom [11:36] * vila nods [11:36] module-locale dict of what ? [11:36] vila: see [11:37] I've caught that in pdb, and there's no .pack file, and the dict of streams is empty [11:37] yeah, this permissiondenied on .pack files never made sense to me [11:38] oh, you mean the _file_streams dict ? [11:38] it's a race, I'm pretty sure, PermissionDenied is "other worker hasn't closed file yet", and this KeyError looks like "other worker didn't create/already deleted file" [11:38] someone loved globals... [11:40] hmm, so the cure may just be to catch/ignore that error ? [11:40] I don't seem to have an open bug for this though [11:40] [11:41] or ?start=80 is better [11:41] shows it went from randomly failing to always. [11:42] vila: the races certainly seem to be hit much more often now, which isn't the location handling change [11:47] and the path is certainly wrong in these cases [11:48] but I think that's just cosmetic [12:06] man, r6124 is a mess. [12:08] wgz: pqm switch :-/ [12:17] what tag did we say we'd use for test failures? [12:19] 'test-falure' seems to be what you used last vila :) [12:19] * wgz corrects the spelling [12:20] yup test-failure, keeping selftest for bugs related to the command itself [12:21] I don't tyops when typing tags, lp procides completion, yet another fullermd hoax [12:21] *provides [12:21] :) [12:36] I would never dream of trying to pin such a falure on you... [13:42] vila: so, I don't really want to block ~vila/bzr/config-command [13:42] vila: but I do think that the increased number of roundtrips is an issue we should fix [13:43] and the fact that this introduces VFS calls where previously they weren't necessary [13:44] well, it is probably more correct to say that these calls were not done at all and that was a bug [13:47] `bzr config` wasn't intended to work for remote branches in its first incarnation, the fact that it worked was lucky at best, buggy at worst [13:48] hmm [13:48] I think the *result* is now correct, don't let the better be the enemy of the good... [13:48] so I guess this is a fundamental issue with branch stacks/stores at the moment [13:48] not specific to this branch [13:48] * jelmer ponders [13:49] vila: r=me, I'll work on a branch that fixes the VFS use for branch stacks [13:50] jelmer: thanks ! [14:16] jelmer: hold on, on a second look, there is no lock involved there 8-/ [14:17] jelmer: what triggers the additional calls is 'self.transport = branch.control_transport' which is a property for remote branches and accessing it triggers an ensure_real call ... [14:22] jelmer: talk about black magic... [14:23] jelmer may be just the person to resolve that :) [14:31] vila: accessing any transport triggers _ensure_real I think [14:32] yeah, it seems :-/ [14:33] jelmer: I'm looking at it, I'll let you know how it goes [14:33] good job GRiD. [14:34] jelmer: but by the look of it, all remote branch usages seem to be impacted (I thought only `bzr config` was) [14:35] the cat being already out, better fix it asap [14:35] GRiD: will try and suggest a less hairy bug next time [14:35] :) [14:40] jelmer: crap, I remember now, RemoteConfig implements get_config_file but neither remove_option nor set_config_file, [14:40] jelmer: I'll file bugs for the missing ones and still look at plugging get_config_file [14:41] vila: I'm working on RemoteBranchStore at the moment [14:41] jelmer: ghaaa, there are Branch.get_config_file *and* BzrDir.get_config_file 8-( More code duplication ahead :-/ [14:42] jelmer: you'll need a RemoteControlDirStore too... [14:46] jelmer: only load and save should need to be smartified, the IniFileStore.__init__ may need some massaging... It's a shame there is no easier way [14:46] bah, and external_url [14:49] vila: yeah, the fact that it takes a transport is an issue [14:49] vila: I'm wondering whether to add another subclass [14:49] The issue [14:50] _load_content and _save_content may be extracted from load/save, that's the part that needs a transport [14:51] I'd rather not duplicate nor change the logic around that [14:51] ok [14:51] class IniTransportStore(IniFileStore) ? [14:51] that leaves external_url but it should be trivial to re-implement so duplicating it is good enough [14:52] and then IniSmartStore ? [14:53] yeah, which also derives from IniFileStore [14:53] wgz :) no worries, i learned some internals which was the goal. admittedly at the expensive of my hacking time for my main os project [14:53] jelmer: sounds good [14:56] jelmer: it doesn't make a lot of sense that a *single* get_bytes() requires >10 hpss pre-requisite calls... [14:58] jelmer: there may be a simpler approach, [14:59] hmm, almost, nm [15:34] I'm trying to work with the new colocated branches support, but I'm running into lots of UI bugs. [15:35] Should I keep filing different bugs for everything I find? Or is that just wasting Jelmer's time? [15:35] if you're now on the latest bzr.dev rev, keep filing bugs. [15:35] nmb: you might want to wait until my current set of colocated branch MPs lands [15:36] ah, there are a few more to go through, that's right [15:36] * wgz needs to look at one of the reviews again [15:36] I'm on the latest bzr.dev now, but I can certainly wait for MPs to land. [15:36] nmb: if you could think/document the user side as you go, that would also be really helpful [15:36] Perhaps I should be reviewing colocated proposals [15:36] and any other thoughts about interface and so on. [15:37] I would love to look into the documentation stuff [15:37] switch is an interface I'm wondering about now [15:37] nmb: :) [15:37] Do we need "bzr switch file:,branch=other" or can we DWIM it to mean "bzr switch other" [15:38] nmb: see the link wgz just posted [15:38] using -b will do the right thing when that change lands. [15:39] Got it. Very nice. [15:39] If I were reviewing that MP, I'd like to see an updated docstring for "bzr switch" in the same revision [15:41] hm, I'm torn on that. [15:41] Currently `bzr help switch` does cover various subcases, but I think we tend to put too much of that in the main command help currently. [15:42] ...and I once again spend too long typing my sentence [15:42] and thus start and and with the same word... [15:42] *and end [15:42] I think that's going to be a generic issue with the overall program of integrating colocated branches... [15:42] nmb: just reported bug 891671 which you seem to be hitting as well [15:42] Launchpad bug 891671 in Bazaar "active colocated branch when it is being created in empty bzrdir" [High,Triaged] https://launchpad.net/bugs/891671 [15:43] Do we mention them in every docstring? [15:43] yeah. [15:44] Yep, your 891671 is something I was about to file on. See also 891667 for a separate UI bug. [15:47] I've got to run, but let me say that the reason I'm running into these bugs now is because I'm trying to make bzr-colo work in native colocated workspaces... [15:47] nmb: cool! [15:48] I'll be working more on that later today, but if I should wait for some more particular branches to land, then I can wait. [15:49] with a bit of luck those branches will have landed by then [16:02] wgz: did you see my reply on https://code.launchpad.net/~jelmer/bzr/branch-url-identifies-branch/+merge/82341 ? [16:04] jelmer: yes, that's what was refering to earlier [16:05] the main remaining confusion, if you're saying segement parameters are (percent escaped) url path sections [16:06] is that bzrdir is still dealing in utf-8 'branch names' [16:06] it's unclear where the lines are drawn in the code between: [16:06] * unicode branch name from user input [16:06] * ??? [16:06] * url encoded segment parameter value [16:07] wgz: bzrdir deals with unicode branch names in its public API [16:07] the colo switch mp is nice because it's clear where transition happens, and it's all in one place [16:08] wgz: only its helper for reading the branch-list file uses utf8 [16:08] but really utf-8 and not %-encoding? [16:08] yes [16:08] wgz: I can change that to be unicode too, but that would mean needlessly decoding/encoding the branch names there [16:09] we do a lot of that currently. :) [16:11] wgz: not a good reason to add more.. [16:11] especially as this is all implementation-specific, it's not exposed in the API [16:14] so, ideally when reading code anywhere in bzrlib it should be clear what type of the variable is [16:15] having names of things sometimes unicode, sometimes utf-8 bytes, sometimes url sections, is bad [16:16] which is an existing problem. _read_branch_list/_write_branch_list is pretty localised at least, it's just a pain for callers to have to worry about encoding [16:17] wgz: I can at least at comments about it in the docstring I guess.. [16:18] I think all your bits are now correctly documented at least. [16:22] okay, you now have like, five things to land. go nuts (in the correct order :) [16:22] \o/ [16:23] * jelmer goes wild [16:23] wgz: thanks again for the reviews [16:23] ...and five new hpss branches needing review... >_< [16:24] wgz: btw, are you still in a weekend mood or something? [16:24] wgz: and you're not even the PP ;) [16:25] nmb: he;s warming up for next week ;) [16:25] have been trying to resolve babune issues today, and 'w' doubles up as 'windows' [16:25] I'll stick to filing mountains of bugs [16:31] wgz: ah :-) [16:32] jelmer: what is the way to find out the current checked out branch? My abstraction in bzr-colo needs access to that. [16:33] nmb: BzrDir.get_branch_reference() [16:34] nmb: BzrDir.get_branch_reference(name=None) [16:35] jelmer: Is that a URL or a branch object? [16:36] nmb: it returns a URL [16:36] dammit, we *did* have one already, bug 788130, how did I miss that vila... [16:36] Launchpad bug 788130 in Bazaar "Intermittent test_branch_local_remote failure on windows: permission denied on .pack file" [High,Confirmed] https://launchpad.net/bugs/788130 [16:37] wgz: you even commented on it ;) [16:38] this rules out any path mangling right ? [16:38] and referenced it from my mp... [16:38] well, at least related to the big boom you referred to earlier [16:38] yeah, this is a pre-existing issue, but something have made it much more prevelent [16:39] like not the path changes, but the other server stuff that landed subsequently (while the path changes were masking everything) [16:39] *likely [16:41] :-/ [17:48] jelmer: in the tests for splitting segments, can you explain these assertions to me? [17:48] [17:50] I've got a fix for bug 842233 that I think preserves your intentions, but doesn't pass those checks [17:50] Launchpad bug 842233 in Bazaar "InvalidURL from tests for local_path_from_url on windows" [Medium,Confirmed] https://launchpad.net/bugs/842233 [17:51] * jelmer looks [17:55] wgz: it looks like an artefact of the way split/join are used in split_segment_parameters [17:56] wgz: and I can't think of a reason why that slash would be necessary [17:56] cool. === deryck is now known as deryck[lunch] [19:04] don't think we didn't see you sneaking up the HPSS calls count there jelmer :P === deryck[lunch] is now known as deryck [19:16] wgz: (-: [19:23] wgz: fortunately rmbranch-colo failed in pqm [19:25] yeah, I saw it was going to and put some more comments in the mp [19:25] same basic confusion [19:26] strip_trailing_slash operates on urls, local_path_from_url returns a path, therefore: [19:26] strip_trailing_slash(local_path_from_url(path)) [19:26] is invalid. [19:27] the tests also break on windows, file:///a isn't valid. [19:29] but something like this is needed, otherwise I get failing tests due to urls like: [19:30] chroot-13432:///,key=val/ [19:31] because some other parts of url handling are *adding* a trailing slash, which then changes the meaning of urls with segments smuggled on the end [19:31] it's messy. [19:32] the boundaries between local paths, urls, and urls-plus-segments just aren't clear enough [19:34] wgz: my changing of strip_trailing_slash was just moving it up the call stack one level IIRC [19:35] and just used for the file part of urls IIRC [19:35] it moved it from inside to outside [19:36] was file_relpath(strip_trailing_slash(url_base), strip_trailing_slash(url)) [19:37] became strip_trailing_slash(local_path_from_url(url_base)) ...etc [19:37] just switching that back means your test_remove_colo fails again though. [19:38] strip_trailing_slash needs to be read as 'strip_trailing_slash_FROM_URL' [20:01] wgz: I'm not sure I follow - aren't the bits we're looking at only used for the file path of URLs? [20:06] in Debian's ‘bzr-gtk’ source package version 0.100.0+bzr737-2.1 the ‘nautilus-bzr’ package has been dropped [20:07] because Debian's Nautilus is now GNOME 3 [20:07] does that mean the Nautilus integration is now gone? can we expect it to return soon? [20:07] [20:08] Debian bug 644689 in nautilus-bzr "nautilus-bzr: Please transition to nautilus 3 and GObject introspection" [Serious,Fixed] [20:23] bignose: hi [20:23] bignose: somebody needs to update it; it's on my list of things to do, but not very high [20:23] jelmer: howdy [20:24] an earlier changelog entry explicitly logs the change “Support nautilus 3.0.”, so why did the NMU remove the package for not supporting Nautilus 3? [20:28] bignose: it's not just nautilus 3, it's also moving to pygi instead of pygtk [20:29] hmm, though it looks like that porting work has in theory also been done [20:30] either way, somebody needs to test nautilus-bzr with nautilus 3, fix where necessary and reupload [20:30] the removal of nautilus-bzr was done by the GNOME team, not by the bzr maintainers [20:31] jelmer: but they were correct to do so, yes? [20:32] bignose: yes, that was before we had switch bzr-gtk in unstable to the gtk3 version [21:03] Hi people! I am facing a small problem in python with bzr. [21:04] which class and method I have to call to create a workingTree is not avaiolable through python? [21:05] any ideas?! [21:15] MrSmile: see doc/developers/overview.txt then the relevent docstrings, and referring to bzrlib/builtins.py for what the bzr script commands do can also be useful [21:16] otherwise, you'll need to ask a more specific question, ideally saying what you're actually trying to do and what code you've got currently [21:16] yes, if I use the bzr script commands, I will have to change the working directory of python, which I really don't want. [21:16] So far I get everything handled. [21:17] I wrote a try, catch routine that if I receive the exception "errors.NotBranchError", that I create there the workingDirectory throuh python with the bzrlibs. [21:17] this is all about. [21:18] jelmer: I'm not completely clear what you mean, but we're not just dealing with urls here, file_relpath converts the url to a filesystem path [21:18] i mean, path [21:18] filesystem path, sorry. [21:19] MrSmile: post your code? I don't understand what you're actually trying to do :) [21:19] okay, I do it now. [21:19] (reading the docs for the basics is a good start regardless though) [21:22] http://pastebin.com/raw.php?i=sYSxUqtC [21:23] I want in the Exception Block, to create the branch branch in the desired directory in the filesystem. [21:23] this is my main problem. [21:24] okay, "open" is for existing branches. [21:24] exaclty! [21:24] this is a routine, that if one exists, I can work further. [21:24] now, it is like the 1st run, if there is no branch in that directoy. [21:25] i want python with the bzrlib to create one for me in this directory, in the exception block. [21:25] which I did manually by calling through python the console application "bzr init", which is not the clean and nice way. [21:26] any idea to make the "bzr init" command, through the bzrlib ?! [21:27] okay, you have two options. [21:27] yes, please [21:28] both of which involve you looking at cmd_init in bzrlib/builtins.py so I suggest you do that now [21:28] the first is calling using the cmd_init class [21:29] where is the class?! [21:29] the second is going through the steps it does yourself, which basically involves getting a bzrdir then calling create_branch (and then create_tree) [21:29] ^line 1864, use your text editor's find [21:30] okay [21:31] jelmer: ping [21:32] or jam, I have few questions about bzr-service [21:39] http://people.canonical.com/~mwh/bzrlibapi/bzrlib.bzrdir.html is a module [21:40] and BzrDir want's paramters, like transport... [21:44] have a nice day. [21:44] bye [21:46] hm, the bzrlib api claims another victim. [21:47] should have just said "pass the dir as the third param to the subprocess call" [21:47] using bzrlib at all requires a level of ability in python, and there are pointless speedhumps still [21:50] ccxCZ: hi [21:51] hello [21:51] hi jelmer [21:52] wgz, another victim trying to write a hook? [21:52] we should really do a general mapping to shell things [21:52] I'm quite interested in in bzr-service as bzr startup is insanely slow (about a second) to be used to decorate a prompt [21:53] but I don't see the protocol documented anywhere [21:53] i suspect only in the code [21:53] for that plugin [21:53] no, he just wanted something nicer than subprocess.call(["bzr", "init"]) but nothing any more complex [21:53] you can talk to jam on here who wrote it [21:53] ccxCZ: one second is quite slow though [21:53] ah [21:54] an intermediate command layer wbn [21:54] yeah, called three times to get all info I need [21:54] apart from several quirks using cmd instances could work. [21:54] and bzr shell insists on connecting to remote server when ran on bound branch [21:54] and at least is then a path to taking those abstrations out so there's less reopening and reclosing and relocking and so on [21:56] ccxCZ: jam is indeed the person to talk to. I've run bzr-service a couple of times in the past but am not familiar wiht its internals [21:58] how do you use it then? it needs some other endpoint to talk to [21:58] wgz, i think perhaps something a bit separate than command instances [21:58] since they have a fair bit of commandline stuff [21:59] possibly a good way to tackle it is to start writing tests at this level [21:59] ccxCZ: "bzr start-service" [21:59] hmm, I see the C client, but since my shell can talk to tcp & unix sockets I'd rather avoid unnecessary exec()s [22:00] no usage instructions in the client either [22:01] poolie: is as simple as I can make using a cmd instance [22:04] ccxCZ: it's probably best to talk to jam [22:04] ccxCZ: it's been a long time since I touched bzr-service, and that was only briefly [22:04] okay [22:05] ccxCZ: there are some alternatives, if you're interested in hearing about those.. [22:05] indeed [22:05] go on [22:05] ccxCZ: you could write a trivial bzr plugin that does the three things you need at once, and then exits [22:06] ccxCZ: without loading plugins the overhead of running "bzr ls" is 0.2 seconds here [22:06] ccxCZ: what version of bzr are you using, and what plugins? [22:06] and what exactly do you need for your prompt? [22:08] info, revno, stat [22:08] gz wow i wish it was faster to get to just seeing the code in the web ui [22:08] the thing is the behavior is dependent on the output of info (if the branch is standalone, bound or lightweight co) [22:09] http://paste.pocoo.org/show/509443/ [22:10] ccxCZ: do you have an example of what your prompt looks like? [22:10] poolie: I should have just given my local sever url, lack of syntax highlighting and all :) [22:11] so... [22:11] some of that i blame python :) [22:12] __main__ dance etc [22:12] it's styleable, I wrote the bzr version vcs_info that is now bundled with zsh [22:12] poolie: I believe most of it will be python [22:12] but we could move some more of that into initialize() and [22:12] poolie: yes, our fault is really the with block, but that's pretty bad [22:12] i think probably we want bzrlib.midlevel.init(argv[1]) [22:12] something like that [22:12] ccxCZ: ah, so I guess a plugin won't really work for you then? [22:13] having to call builtin_command_names() for the side effect of calling the (private) _register_builtin_commands() is particularly good. [22:13] it would help, but I think using resident process would be much neater [22:14] it could also speed up regular zsh work [22:16] jelmer: basically the thing is that I have home under bzr, and I want my prompt scream at me if I have uncommitted changes [22:16] but I have to first check that I don't call stat on lw checkout that is networked [22:18] the current vcs_info _could_ be rewritten as a bzr plugin, though I anticipate some resistance depending upon unofficial plugin in a script bundled with zsh [22:18] resistance to* [22:21] perhaps you can merge it to bzr [22:21] that would be great [22:23] * ccxCZ reads what the vcs_info script actually does [22:26] I think an info-like command that prints data according to supplied template would work, if one can supply conditionals so we can eliminate connecting to remote repositories [22:26] here's the zsh script btw http://wpr.cz/ccx/paste/2011-11-17/0.html [22:29] or maybe do it the other way around, is there way to tell branch type without executing bzr? [22:32] yeah, you can just look in .bzr [22:32] for example [22:32] is there a .bzr/repository? [22:33] is there a .bzr/branch [22:33] is there a .bzr/branch/location [22:33] that may be faster than starting python [22:33] and pretty feasible to do in zsh [22:34] indeed, but I haven't seen any comprehensive documentation on the layout of .bzr, so if you point me to one I can implement that [22:34] btw I timed python and bzr startup [22:34] time: 0.17s user 0.03s system 98% cpu 0.208 total python -c 'print "hello"' [22:35] time: 0.75s user 0.15s system 98% cpu 0.909 total bzr --version [22:35]