| 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:07 |
| poolie | that looks odd | 01:16 |
| poolie | i guess that means 'there is no trunk registered' | 01:16 |
| poolie | there is no project of that name at all | 01:17 |
| poolie | obviously it's a crappy error message | 01:17 |
| zyga-afk | mwhudson, you are silly | 01:20 |
| zyga-afk | mwhudson, s/script/tool/ | 01:20 |
| mwhudson | zyga-afk: ah ofc | 01:21 |
| 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:22 |
| mwhudson | maybe i'll do some launchpad hacking tonight... | 01:23 |
| wgz | back home | 01:29 |
| lifeless | mwhudson: :) | 01:31 |
| === lifeless is now known as subunit | ||
| === subunit is now known as lifeless | ||
| 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:45 |
| 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:46 |
| 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) | 01:47 |
| === zyga-afk is now known as zyga-really-afk | ||
| 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:22 |
| 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:23 |
| poolie | hi wgz | 02:51 |
| poolie | lunch time | 02:51 |
| GungaDin | How do I do bzr patch on Windows? | 05:31 |
| jo-erlend | GungaDin :) | 05:36 |
| 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:37 |
| spiv | jo-erlend: http://doc.bazaar.canonical.com/bzr.2.4/en/user-reference/annotate-help.html | 05:39 |
| spiv | And the GUI versions in bzr-gtk/qbzr (bzr gannotate/bzr qannotate) are quite nice. | 05:40 |
| jo-erlend | spiv, nice! Thank you :) | 06:34 |
| 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? | 08:31 |
| 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:09 |
| vila | wgz: tell mgz: \o/ windows slave down to 11 failures ! | 09:40 |
| vila | wgz: I'm sure you will love to fix the 3 TestTreeTransform ones :-D | 09:42 |
| mgz | morning all | 09:48 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| Sindikat | vila: it's not that distributed then | 09:54 |
| 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:56 |
| 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:57 |
| vila | Sindikat: have a look at http://doc.bazaar.canonical.com/bzr.dev/en/tutorials/index.html | 09:58 |
| === zyga is now known as zyga-afk | ||
| mgz | hey, launchpad now has a cute(ish) down page | 10:33 |
| 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:39 |
| 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:47 |
| mgz | how are you accessing the server currently? | 10:49 |
| 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:50 |
| 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:57 |
| mgz | and bzr will remember the push and pull locations, so you can easily have a local mirror | 10:58 |
| wgz | why is there a module-locale dict of handles in bzrlib.transport... | 11:32 |
| 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:33 |
| wgz | oh, and the bt.test_transform ones are just exception stringifying | 11:34 |
| wgz | 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 |
| wgz | <http://babune.ladeuil.net:24842/view/Windows/job/selftest-windows/503/> <- moment of boom | 11:35 |
| * 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:36 |
| 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:37 |
| 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:38 |
| 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:40 |
| wgz | <http://babune.ladeuil.net:24842/view/Windows/job/selftest-windows/593/testReport/junit/bzrlib.tests.blackbox.test_branch/TestRemoteBranch/test_branch_remote_remote/history/?start=100> | 11:40 |
| wgz | or ?start=80 is better | 11:41 |
| wgz | shows it went from randomly failing to always. | 11:41 |
| wgz | vila: the races certainly seem to be hit much more often now, which isn't the location handling change | 11:42 |
| wgz | and the path is certainly wrong in these cases | 11:47 |
| wgz | but I think that's just cosmetic | 11:48 |
| wgz | man, r6124 is a mess. | 12:06 |
| vila | wgz: pqm switch :-/ | 12:08 |
| wgz | what tag did we say we'd use for test failures? | 12:17 |
| wgz | 'test-falure' seems to be what you used last vila :) | 12:19 |
| * wgz corrects the spelling | 12:19 | |
| vila | yup test-failure, keeping selftest for bugs related to the command itself | 12:20 |
| vila | I don't tyops when typing tags, lp procides completion, yet another fullermd hoax | 12:21 |
| vila | *provides | 12:21 |
| vila | :) | 12:21 |
| fullermd | I would never dream of trying to pin such a falure on you... | 12:36 |
| 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:42 |
| jelmer | and the fact that this introduces VFS calls where previously they weren't necessary | 13:43 |
| vila | well, it is probably more correct to say that these calls were not done at all and that was a bug | 13:44 |
| 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:47 |
| 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:48 | |
| jelmer | vila: r=me, I'll work on a branch that fixes the VFS use for branch stacks | 13:49 |
| vila | jelmer: thanks ! | 13:50 |
| vila | jelmer: hold on, on a second look, there is no lock involved there 8-/ | 14:16 |
| 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:17 |
| vila | jelmer: talk about black magic... | 14:22 |
| wgz | jelmer may be just the person to resolve that :) | 14:23 |
| jelmer | vila: accessing any transport triggers _ensure_real I think | 14:31 |
| vila | yeah, it seems :-/ | 14:32 |
| vila | jelmer: I'm looking at it, I'll let you know how it goes | 14:33 |
| wgz | good job GRiD. | 14:33 |
| vila | jelmer: but by the look of it, all remote branch usages seem to be impacted (I thought only `bzr config` was) | 14:34 |
| 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:35 |
| 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:40 |
| 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:41 |
| vila | jelmer: you'll need a RemoteControlDirStore too... | 14:42 |
| 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:46 |
| 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:49 |
| vila | _load_content and _save_content may be extracted from load/save, that's the part that needs a transport | 14:50 |
| 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:51 |
| vila | and then IniSmartStore ? | 14:52 |
| 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:53 |
| vila | jelmer: it doesn't make a lot of sense that a *single* get_bytes() requires >10 hpss pre-requisite calls... | 14:56 |
| vila | jelmer: there may be a simpler approach, | 14:58 |
| vila | hmm, almost, nm | 14:59 |
| nmb | I'm trying to work with the new colocated branches support, but I'm running into lots of UI bugs. | 15:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| jelmer | nmb: see the link wgz just posted | 15:38 |
| wgz | using -b will do the right thing when that change lands. | 15:38 |
| 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:39 |
| 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:41 |
| 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:42 |
| ubot5 | Launchpad bug 891671 in Bazaar "active colocated branch when it is being created in empty bzrdir" [High,Triaged] https://launchpad.net/bugs/891671 | 15:42 |
| nmb | Do we mention them in every docstring? | 15:43 |
| wgz | yeah. | 15:43 |
| nmb | Yep, your 891671 is something I was about to file on. See also 891667 for a separate UI bug. | 15:44 |
| 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:47 |
| 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:48 |
| jelmer | with a bit of luck those branches will have landed by then | 15:49 |
| jelmer | wgz: did you see my reply on https://code.launchpad.net/~jelmer/bzr/branch-url-identifies-branch/+merge/82341 ? | 16:02 |
| wgz | jelmer: yes, that's what was refering to earlier | 16:04 |
| wgz | the main remaining confusion, if you're saying segement parameters are (percent escaped) url path sections | 16:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| wgz | we do a lot of that currently. :) | 16:09 |
| 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:11 |
| wgz | so, ideally when reading code anywhere in bzrlib it should be clear what type of the variable is | 16:14 |
| wgz | having names of things sometimes unicode, sometimes utf-8 bytes, sometimes url sections, is bad | 16:15 |
| 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:16 |
| jelmer | wgz: I can at least at comments about it in the docstring I guess.. | 16:17 |
| wgz | I think all your bits are now correctly documented at least. | 16:18 |
| wgz | okay, you now have like, five things to land. go nuts (in the correct order :) | 16:22 |
| jelmer | \o/ | 16:22 |
| * jelmer goes wild | 16:23 | |
| jelmer | wgz: thanks again for the reviews | 16:23 |
| wgz | ...and five new hpss branches needing review... >_< | 16:23 |
| jelmer | wgz: btw, are you still in a weekend mood or something? | 16:24 |
| nmb | wgz: and you're not even the PP ;) | 16:24 |
| 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:25 |
| jelmer | wgz: ah :-) | 16:31 |
| nmb | jelmer: what is the way to find out the current checked out branch? My abstraction in bzr-colo needs access to that. | 16:32 |
| jelmer | nmb: BzrDir.get_branch_reference() | 16:33 |
| jelmer | nmb: BzrDir.get_branch_reference(name=None) | 16:34 |
| nmb | jelmer: Is that a URL or a branch object? | 16:35 |
| jelmer | nmb: it returns a URL | 16:36 |
| wgz | dammit, we *did* have one already, bug 788130, how did I miss that vila... | 16:36 |
| ubot5 | 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:36 |
| vila | wgz: you even commented on it ;) | 16:37 |
| 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:38 |
| 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:39 |
| vila | :-/ | 16:41 |
| wgz | jelmer: in the tests for splitting segments, can you explain these assertions to me? | 17:48 |
| wgz | <http://paste.ubuntu.com/741413/> | 17:48 |
| wgz | I've got a fix for bug 842233 that I think preserves your intentions, but doesn't pass those checks | 17:50 |
| ubot5 | Launchpad bug 842233 in Bazaar "InvalidURL from tests for local_path_from_url on windows" [Medium,Confirmed] https://launchpad.net/bugs/842233 | 17:50 |
| * jelmer looks | 17:51 | |
| jelmer | wgz: it looks like an artefact of the way split/join are used in split_segment_parameters | 17:55 |
| jelmer | wgz: and I can't think of a reason why that slash would be necessary | 17:56 |
| wgz | cool. | 17:56 |
| === deryck is now known as deryck[lunch] | ||
| wgz | don't think we didn't see you sneaking up the HPSS calls count there jelmer :P | 19:04 |
| === deryck[lunch] is now known as deryck | ||
| jelmer | wgz: (-: | 19:16 |
| jelmer | wgz: fortunately rmbranch-colo failed in pqm | 19:23 |
| wgz | yeah, I saw it was going to and put some more comments in the mp | 19:25 |
| wgz | same basic confusion | 19:25 |
| 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:26 |
| wgz | the tests also break on windows, file:///a isn't valid. | 19:27 |
| wgz | but something like this is needed, otherwise I get failing tests due to urls like: | 19:29 |
| wgz | chroot-13432:///,key=val/ | 19:30 |
| 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:31 |
| wgz | the boundaries between local paths, urls, and urls-plus-segments just aren't clear enough | 19:32 |
| jelmer | wgz: my changing of strip_trailing_slash was just moving it up the call stack one level IIRC | 19:34 |
| jelmer | and just used for the file part of urls IIRC | 19:35 |
| wgz | it moved it from inside to outside | 19:35 |
| wgz | was file_relpath(strip_trailing_slash(url_base), strip_trailing_slash(url)) | 19:36 |
| 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:37 |
| wgz | strip_trailing_slash needs to be read as 'strip_trailing_slash_FROM_URL' | 19:38 |
| 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:01 |
| bignose | in Debian's ‘bzr-gtk’ source package version 0.100.0+bzr737-2.1 the ‘nautilus-bzr’ package has been dropped | 20:06 |
| 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:07 |
| bignose | <URL:http://bugs.debian.org/644689> | 20:07 |
| ubot5 | Debian bug 644689 in nautilus-bzr "nautilus-bzr: Please transition to nautilus 3 and GObject introspection" [Serious,Fixed] | 20:08 |
| 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:23 |
| 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:24 |
| jelmer | bignose: it's not just nautilus 3, it's also moving to pygi instead of pygtk | 20:28 |
| jelmer | hmm, though it looks like that porting work has in theory also been done | 20:29 |
| 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:30 |
| bignose | jelmer: but they were correct to do so, yes? | 20:31 |
| jelmer | bignose: yes, that was before we had switch bzr-gtk in unstable to the gtk3 version | 20:32 |
| MrSmile | Hi people! I am facing a small problem in python with bzr. | 21:03 |
| MrSmile | which class and method I have to call to create a workingTree is not avaiolable through python? | 21:04 |
| MrSmile | any ideas?! | 21:05 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| MrSmile | http://pastebin.com/raw.php?i=sYSxUqtC | 21:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| MrSmile | any idea to make the "bzr init" command, through the bzrlib ?! | 21:26 |
| wgz | okay, you have two options. | 21:27 |
| MrSmile | yes, please | 21:27 |
| 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:28 |
| 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:29 |
| MrSmile | okay | 21:30 |
| ccxCZ | jelmer: ping | 21:31 |
| ccxCZ | or jam, I have few questions about bzr-service | 21:32 |
| MrSmile | http://people.canonical.com/~mwh/bzrlibapi/bzrlib.bzrdir.html is a module | 21:39 |
| MrSmile | and BzrDir want's paramters, like transport... | 21:40 |
| MrSmile | have a nice day. | 21:44 |
| MrSmile | bye | 21:44 |
| wgz | hm, the bzrlib api claims another victim. | 21:46 |
| 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:47 |
| jelmer | ccxCZ: hi | 21:50 |
| ccxCZ | hello | 21:51 |
| poolie | hi jelmer | 21:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:56 |
| 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:58 |
| 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 | 21:59 |
| ccxCZ | no usage instructions in the client either | 22:00 |
| wgz | poolie: <lp:~gz/+junk/call_bzr_init> is as simple as I can make using a cmd instance | 22:01 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:08 |
| ccxCZ | http://paste.pocoo.org/show/509443/ | 22:09 |
| 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:10 |
| poolie | so... | 22:11 |
| poolie | some of that i blame python :) | 22:11 |
| 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:12 |
| 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:13 |
| ccxCZ | it could also speed up regular zsh work | 22:14 |
| 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:16 |
| 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:18 |
| poolie | perhaps you can merge it to bzr | 22:21 |
| ccxCZ | that would be great | 22:21 |
| * ccxCZ reads what the vcs_info script actually does | 22:23 | |
| 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:26 |
| ccxCZ | or maybe do it the other way around, is there way to tell branch type without executing bzr? | 22:29 |
| poolie | yeah, you can just look in .bzr | 22:32 |
| poolie | for example | 22:32 |
| poolie | is there a .bzr/repository? | 22:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| ccxCZ | if we implement bzr info in shell I already got 30% speedup | 22:36 |
| 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:37 |
| 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:40 |
| ccxCZ | okay | 22:41 |
| ccxCZ | that should be all the info I need | 22:42 |
| ccxCZ | is revno easilly reachable? | 22:42 |
| ccxCZ | .bzr/branch/last-revision it seems | 22:45 |
| ccxCZ | which is missing in bound branches | 22:45 |
| 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 | 22:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!