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