| achiang | hello, can someone explain what i'm doing wrong here? http://pastebin.ubuntu.com/539211/ | 00:03 |
|---|---|---|
| achiang | trying to make it so that my streamflow project uses my personal email, not my work email | 00:03 |
| achiang | according to the help i found on google, that syntax i used should work... | 00:03 |
| mwhudson | achiang: what file is that top section from? | 00:04 |
| mwhudson | i think it needs to be ~/.bazaar/locations.conf, not ~/.bazaar/bazaar.conf | 00:04 |
| achiang | mwhudson: ~/.bazaar/bazaar.conf | 00:04 |
| achiang | mwhudson: hm, interesting | 00:04 |
| achiang | i will try again | 00:04 |
| achiang | mwhudson: yes, that was it, thank you | 00:05 |
| mwhudson | achiang: np | 00:06 |
| achiang | mwhudson: the problem was entirely mine. i read this page too fast -- http://wiki.bazaar.canonical.com/ConfiguringBzr | 00:06 |
| poolie | hi mwh, achiang | 00:06 |
| achiang | the documentation clearly says locations.conf, and i misread it | 00:06 |
| achiang | so your documentation is good, i am just dumb. :) | 00:07 |
| achiang | poolie: hi | 00:07 |
| maxb | $ bzr resolve --take-this .bzrignore | 00:45 |
| maxb | 0 conflict(s) resolved, 1 remaining | 00:45 |
| maxb | erm, what? | 00:45 |
| maxb | (yes, .bzrignore is conflicted) | 00:45 |
| maxb | text conflicted, that is | 00:45 |
| spiv | maxb: :( | 00:49 |
| lifeless | maxb: bzr resolve --take-this .bzrignore.THIS ? | 00:53 |
| poolie | maxb, iirc what vila said, it does not mark it as resolved | 00:55 |
| poolie | it should | 00:55 |
| poolie | we should distinguish "do this to the file" from "mark the conflict as solved" | 00:55 |
| thumper | hey | 01:44 |
| thumper | how do I set append only for an existing branch on LP? | 01:44 |
| spiv | thumper: by editing the branch.conf file, I think :( | 01:52 |
| thumper | what? | 01:53 |
| thumper | that's a bit primitive | 01:53 |
| spiv | thumper: I expect vila's config work will provide UI for this fairly soon | 01:53 |
| thumper | spiv: what do I need to add? | 01:53 |
| thumper | I'm sure hitchhiker can work wonders | 01:53 |
| spiv | append_revisions_only = True | 01:54 |
| spiv | Or open the branch object and call br.set_append_revisions_only(True) | 01:54 |
| poolie | thumper: thanks for your mail about apis, i'm replying | 02:10 |
| poolie | spiv, maybe we should pair together more | 02:10 |
| poolie | i was thinking of buying a desktop rather than headset mike | 02:10 |
| mkanat | poolie: Any hope of getting my loggerhead changes pushed to LP? | 02:23 |
| mkanat | Or approved, at least. | 02:23 |
| poolie | good question! | 02:23 |
| poolie | did i review but not mark them approved? | 02:23 |
| poolie | or... there are probably more still unreviewed? | 02:23 |
| mkanat | poolie: Ah, I merged them into loggerhead, but the LP branch push MP is still waiting a review. | 02:24 |
| glyph | Hey, I have a workflow hiccup with bzr that I am wondering if you guys can shed some light on. | 02:28 |
| glyph | I frequently encounter diverged branches that I don't really expect | 02:28 |
| glyph | this is mainly in my 'personal preferences' repository, which I keep on several machines | 02:29 |
| glyph | the sort of pattern is this; I'm on a plane, I make some settings adjustment based on some new tidbit of information (like, a shell helper that I didn't realize was doing a DNS lookup or something like that, that I discover because I'm offline) | 02:29 |
| glyph | commit locally | 02:29 |
| thumper | poolie: cool | 02:30 |
| glyph | then later I make changes to the repository on my desktop, push those changes | 02:30 |
| glyph | and then, 30 seconds before I go somewhere, I do a quick 'bzr pull' on my laptop | 02:30 |
| glyph | oops! branches diverged. but my upstream is kind of crappy, so it takes 45 seconds to actually do the SSH handshake with my server, and I'm leaving for a meeting or something, so I just leave without my changes. | 02:31 |
| mkanat | glyph: Ah, you have to do a "bzr merge" in that situation instead. | 02:31 |
| glyph | mkanat: Oh, I know *that*. But 'bzr merge' needs to do the SSH handshake again and deal with RTT again and it's slow. | 02:31 |
| glyph | More importantly, I have to do something interactive | 02:31 |
| maxb | glyph: Perhaps you would be interested in 'bzr merge --pull' (pull if you can, otherwise merge) | 02:32 |
| glyph | maxb: Hmm, maybe that is what I want | 02:32 |
| glyph | although | 02:32 |
| maxb | Of course, you still need to commit and push | 02:32 |
| glyph | what I _really_ want is 'pull if you can, otherwise, put the diverged branch in some helpful location in the same repository, so you can merge from it later' | 02:33 |
| maxb | Well, it's not the greatest of UIs, but that kind of already happens (except for the helpful bit) | 02:35 |
| glyph | haha | 02:36 |
| glyph | maxb: is that bzr's motto? | 02:36 |
| glyph | maxb: 'that already works, except for the helpful bit' | 02:36 |
| maxb | The not-actually-pulled head will be stored in the local repository and visible in 'bzr heads --dead' | 02:36 |
| maxb | you would be able to merge it by revision-id later | 02:36 |
| glyph | woah | 02:36 |
| glyph | that's pretty awesome | 02:36 |
| glyph | so the network I/O actually _does_ happen? | 02:37 |
| maxb | sure, it's not just pretending :-) | 02:38 |
| glyph | well, I knew _some_ did | 02:38 |
| glyph | I didn't realize it actually pulled all of the revs though | 02:38 |
| glyph | so, how about this | 02:40 |
| glyph | if I make a no-tree branch in my branch and then only ever pull into it | 02:41 |
| glyph | then I can just do 'cd upstream; bzr pull' | 02:41 |
| glyph | and then 'cd ..; bzr merge --pull upstream' | 02:41 |
| glyph | when I have a moment to sit and merge later, but potentially no network I/O | 02:41 |
| glyph | hmm, if I do 'bzr get . upstream', it works, but it doesn't appear to use the working directory as a shared repository | 02:42 |
| glyph | the branch in question is ~/something, and I don't want ~ to be a shared repository. 'bzr init-repository .' complains that '.bzr' already exists. | 02:43 |
| glyph | do I have any option here? | 02:43 |
| maxb | erm, possibly | 02:45 |
| maxb | let me test something.... | 02:46 |
| maxb | It's rather cheating quite a lot, but it seems as if 'touch .bzr/repository/shared-storage' convinces bzr to use an existing branch's repository as a shared repository for contained branches | 02:47 |
| glyph | maxb: hmm | 02:49 |
| glyph | maxb: maybe I don't need to do that | 02:49 |
| glyph | now that I'm looking at the output of heads --dead, I can see that it's basically doing what I want | 02:50 |
| glyph | yeah | 02:50 |
| glyph | okay this is cool | 02:50 |
| glyph | maxb: thanks for the info | 02:51 |
| spiv | poolie: it would be interesting to try pairing more | 02:57 |
| spiv | poolie: I'd have to have a bit of a think about headsets etc. | 02:57 |
| poolie | perhaps we should just meet up and actually pair? | 02:57 |
| poolie | i feel a bit buried with stuff i've already started but really there's no reason we couldn't pair on that | 02:58 |
| poolie | or or things you have in train | 02:58 |
| glyph | so, now I think I know how to phrase my request | 03:06 |
| glyph | spiv: there should be a 'bzr merge --last' (or perhaps just the default behavior of 'bzr merge' if there are pulled-but-not-merged revisions) | 03:06 |
| glyph | if 'bzr pull' fails | 03:07 |
| glyph | or "if the branches have diverged" | 03:07 |
| glyph | it looks like 'push' actually fixes the divergent revisions too? this is really neat! | 03:07 |
| glyph | push actually _pulls_ the divergent revisions | 03:07 |
| spiv | glyph: how precisely would you define "last"? | 03:15 |
| maxb | merge --last is an interesting concept. It's roughly equivalent to .git/FETCH_HEAD | 03:15 |
| spiv | glyph: you mean the head most recently added to the repo? | 03:15 |
| glyph | spiv: I *think* that's what I mean, but I don't understand those terms perfectly, so, to be explicit: | 03:16 |
| glyph | bzr pull; oops, diverged; bzr merge # don't do any network I/O, you already have a diverged merge tip, just merge it | 03:17 |
| glyph | I don't really know about .git/FETCH_HEAD, because one of the best things - perhaps _the_ best thing about bzr, is the fact that it prevents me from needing to learn anything at all about git :) | 03:17 |
| spiv | glyph: so the trick is finding the right diverged tip | 04:12 |
| spiv | glyph: maybe you have other tips from doing "bzr merge; bzr revert", or from "bzr uncommit". | 04:13 |
| === BasicPRO is now known as BasicOSX | ||
| glyph | spiv: well, this is why I phrased my requirement that way. | 05:47 |
| glyph | spiv: You could have 'bzr pull' specifically remember which tip is the right one, when the branches have diverged, and have other things wipe that memory | 05:48 |
| glyph | spiv: 'bzr pull; bzr whatever; bzr merge --last' would just say 'Sorry, last command wasn't a pull, I don't know what tip you mean." | 05:53 |
| dmuir | kind of a noob question, but how do I go about manually creating patch files? I've got a situation where I've got two trees with no common base, and I just want to copy over some revisions. | 06:04 |
| dmuir | is it simply `bzr diff -c revno > filename.patch` ? | 06:05 |
| dmuir | and and then `bzr merge filename.patch`? | 06:07 |
| dmuir | hmm, that didn't work | 06:08 |
| peitschie | dmuir: I think you need to use the gnu "patch" command to apply the batch | 06:09 |
| peitschie | it won't handle renames or binary files correctly however | 06:10 |
| dmuir | hmm, ok | 06:10 |
| peitschie | dmuir: give this a try? http://www.cuberick.com/2009/02/merge-bazaar-repositories-with-no.html | 06:11 |
| glyph | dmuir: 'bzr send' | 06:14 |
| glyph | peitschie: woah, that is rad. | 06:15 |
| dmuir | hmm, if I understand the cuberick trick, I'm basically cherrypicking the tree as a whole? | 06:16 |
| dmuir | I'm still getting a bunch of conflicts, but I think they're all fairly straight forward. | 06:17 |
| peitschie | dmuir: sounds about right | 06:17 |
| peitschie | glyph: I think send wants to provide a bundle, which pretty much requires a common ancestor? | 06:18 |
| dmuir | hmm, send crashed on me | 06:19 |
| dmuir | bzrtools's patch seems to do the job reasonably well | 06:27 |
| spiv | glyph: ok, I'd call that option --last-pull in that case. | 06:40 |
| glyph | spiv: really, I just want it to be the default behavior of 'merge' :) | 06:45 |
| spiv | glyph: have a local mirror of the source branch, and have that mirror associated as the parent branch, and you'd have that ;) | 06:47 |
| glyph | spiv: any better way to do the branch-and-shared-repository thing? | 06:57 |
| glyph | it would just be handy to have the local mirror be an empty dir called 'upstream' ;) | 06:58 |
| UnhappyVssUser | In VSS (M****** Source Safe) there are shared files. A file is always in a vss "project" (a directory). If you share it (VSS terminology), the same file can appear in multiple projects. Let's say I have a configuration file "OurCommonConfigs.xml". We have this file in all our Visual Studio projects. But we don't want to manually(!) update it in all places where it is used. When I edit it in project X it should be updated in project Y | 07:27 |
| UnhappyVssUser | possible with GIT? | 07:27 |
| poolie | this isn't the git channel | 07:29 |
| UnhappyVssUser | Err, I mean Bazaar. You see I'm evaluating the various Source control | 07:29 |
| poolie | you could store it in a bzr branch and reference it from all your projects | 07:29 |
| UnhappyVssUser | systems. | 07:29 |
| poolie | by a lnk, or some other means | 07:29 |
| poolie | bzr won't automatically update every checkout of it | 07:29 |
| spiv | glyph: you can do e.g. "bzr init-repo foo --no-trees; cd foo; bzr init .; bzr pull $my_branch; bzr branch $upstream upstream" | 07:30 |
| spiv | glyph: although it might be nicer and simpler to use the bzr-colo plugin | 07:30 |
| UnhappyVssUser | Thanks, I'll look up branch and link benhaviour | 07:31 |
| vila | hi all | 07:33 |
| vila | pingeling about https://code.edge.launchpad.net/~vila/bzr/638451-malformed/+merge/41759 | 07:35 |
| poolie | hi there vila | 07:46 |
| vila | poolie: hey ! | 07:46 |
| poolie | sorry vila, i really wanted to do that today | 07:47 |
| poolie | didn't get to it | 07:47 |
| poolie | :/ | 07:47 |
| vila | Should I just land this mp, I summarized in the cover letter that I addressed the points raised, but I'm always a bit hesitant to do that sort of thing | 07:47 |
| * poolie looks quickly | 07:48 | |
| poolie | i have to go soon | 07:48 |
| vila | poolie: yeah, no worries, I've seen a couple of interesting mails from you :) | 07:48 |
| poolie | does it actually resolve things? | 07:49 |
| poolie | i mean, does it mark the conflict resolved? | 07:49 |
| vila | oh yes | 07:49 |
| poolie | it looks basically ok | 07:49 |
| poolie | so, weak +1 if you're confident to merge it | 07:49 |
| poolie | now i have to go; have a good day! | 07:49 |
| poolie | and weekend | 07:49 |
| vila | poolie: you too ! and thanks ! | 07:49 |
| vila | too slow ;) | 07:50 |
| UnhappyVssUser | Regarding shared VSS files: I have read about the "branch" command but didn't found the "lnk" command in documentation. The branch command creates a new repository! Not really what shared files are. But let's assume I make a branch for this file and put it in a shared repository. When I change the file, I change it in this branch. Then there is another branch (smae repository) which contains the class-files of the program. Is it possi | 07:57 |
| UnhappyVssUser | class files and the "Shared" file in the same physical directory the developer uses to work with (say: "C:\Product\CurrentDev\ProjectA\class1.cs" and "C:\Product\CurrentDev\ProjectA\Options.xml")? Do you think the Visual Studio plugin will be able to handle this situation? | 07:57 |
| vila | UnhappyVssUser: I think poolie meant 'lnk' as in a link to a file that is not part of the branch you're working in but pointing to a file managed in its own branch | 08:00 |
| vila | UnhappyVssUser: the point is that bzr handles trees not individual files when it comes to versioning, and I suspect you don't want this file to be part of every revision in all your project branches | 08:01 |
| vila | UnhappyVssUser: because if you revert to a previous revision you don't want to revert this file too | 08:01 |
| vila | UnhappyVssUser: or not ? | 08:02 |
| vila | UnhappyVssUser: by the way, your previous msgs were truncated making them a bit unclear | 08:04 |
| UnhappyVssUser | vila: Sorry for the truncated texts. Opera browser makes that (if you meant the two lines). | 08:13 |
| vila | UnhappyVssUser: the first one ends with 'It is poss' and the second starts with 'class files and' | 08:14 |
| UnhappyVssUser | It seems I havn't understood the philosophy of bazaar full. Let me explain: VSS is very simple (I hear you laughing, don't!). In a project(directory) you check out your file, edit it and check it in. If you want a version, you "label" it, say "v2.3.44". If you want that version you "get" a "label". too be continued... | 08:18 |
| vila | I'm not laughing, I feel your pain :) | 08:19 |
| UnhappyVssUser | A "shared file" exists in x directories. If you "label" the directory/project and later "get" that "label" the you get also the "shared file" | 08:19 |
| vila | right, so that's a fundamental difference | 08:20 |
| vila | with bzr you don't version files, you version trees | 08:20 |
| UnhappyVssUser | Well, but what do you do if you want to have the same file on multiple places? | 08:21 |
| UnhappyVssUser | Don't tell me you edit all of them manually!!! | 08:22 |
| vila | the question is whether you want this file to follow the history of its containing tree or not | 08:22 |
| vila | UnhappyVssUser: if you revert a tree to a previous revision, do *you* want this file to also revert to this previous revision ? | 08:23 |
| UnhappyVssUser | yes, it should also revert to the previous revision ("label") | 08:24 |
| UnhappyVssUser | I'm looking up the "tree" and what it represents in VSS....if there is such a thing | 08:25 |
| vila | ok, in this case, you're after nested trees, which are not fully implemented (yet) in bzr, but even there, the plan is to nest *trees* not files, so you'll have to put this file in its own directory (AFAIUI) | 08:25 |
| vila | UnhappyVssUser: I suspect a tree is really a label: i.e. the set of (file, revision) that happen to carry this label | 08:26 |
| vila | .. but may be not, (how would updates of the shared files propagate to other labels ?) | 08:27 |
| UnhappyVssUser | I found it in bazaar doc: http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-vss-users.html | 08:27 |
| UnhappyVssUser | A "label" seems to be a tag | 08:27 |
| vila | UnhappyVssUser: right, this page says that Share is N/A | 08:29 |
| vila | UnhappyVssUser: surely the person that wrote it knows VSS (I don't, I *guess* it's closer to CVS than to bzr) | 08:29 |
| fullermd | Well, if you're going to insult CVS... | 08:30 |
| vila | fullermd: hey ! | 08:31 |
| vila | I rarely insult tools anymore these days, they tend to just ignore me when I do that | 08:31 |
| fullermd | They ignore me too, but it's still very cathartic to scream at them. | 08:32 |
| vila | ... another reason is that ISTM, these insults tend to bounce back at me for trusting the tools too much :-D | 08:33 |
| UnhappyVssUser | Ok bazaarians, I'm a friendly person too and this Linus guy makes insults even in pulbic speeches. So I'm not very GIT-friendly. I would prefer Bazaar. When can I expect nested trees? It seems I'm the only guy who has the same file at multiple places. It was not my idea, it's Visual Studio. | 08:41 |
| vila | UnhappyVssUser: not soon enough :-/ But there are plugins which tries to address the same kind of compositing, bzr-externals and... bialix will hate me for forgetting the other... | 08:43 |
| vila | someone help me ? | 08:43 |
| vila | scmproj ! | 08:44 |
| vila | UnhappyVssUser: http://doc.bazaar.canonical.com/plugins/en/ | 08:44 |
| vila | UnhappyVssUser: both externals and scmproj are actively maintained and part of the devs (if not all) are on windows too, so they should be able to help you better than me | 08:46 |
| UnhappyVssUser | vila: Thanks for the link. More to read... | 08:46 |
| UnhappyVssUser | vila: I thank you very much. Very helpful. I'll check the plugins... | 08:47 |
| vila | UnhappyVssUser: you're welcome | 08:47 |
| UnhappyVssUser | have a good day (The boss appeared at my office ...uh) | 08:47 |
| UnhappyVssUser | He does not know of his bazaar luck, yet | 08:48 |
| vila | UnhappyVssUser: quick ! Bring up your facebook page ! Enough of this productivity-enhancing tools discussions !! | 08:49 |
| UnhappyVssUser | lol | 08:49 |
| vila | :) | 08:49 |
| UnhappyVssUser | But honestly, this is his thinking | 08:49 |
| UnhappyVssUser | unfortunately, we must "introduce" changes secretly until they work and present after they are a success. Before: "costs too much", "no effort in this direction" | 08:50 |
| vila | fullermd: by the way, just curious, how would you address this 'shared file' issue in CVS ? | 08:51 |
| vila | UnhappyVssUser: Yeah, I know the feeling :-/ | 08:51 |
| vila | fullermd: CVSROOT/modules tinkering ? | 08:51 |
| fullermd | I s'pose you could "ln -s /some/other/repo/foo,v ." | 08:51 |
| vila | fullermd: naaah, on windows man, no funny symlinks... | 08:52 |
| fullermd | Well, you wouldn't be hosting a CVS repo on windows in the first place... | 08:52 |
| vila | fullermd: pff, cheater :D | 08:52 |
| fullermd | Man, if we're running CVS, cheating is de rigeur :p | 08:53 |
| vila | LOL | 08:53 |
| vila | good to know I can use 'de rigueur' with English people ;) | 08:53 |
| fullermd | Oh, did French borrow that phrase from English too? ;> | 08:54 |
| vila | something like that certainly ;D | 08:55 |
| vila | ha ! window is easy, just one click is enough ! | 09:17 |
| vila | The trouble is to find which one... | 09:17 |
| vila | mgz, jam: For the record, export BZR_SSH=openssh now works for the babune slave *including* using the ssh keys forwarded from the babune master, \o/ | 09:37 |
| mgz | for the further record, what exactly did you need to change vila? | 09:37 |
| vila | hmm | 09:37 |
| vila | the ssh server service should be started by the babune user | 09:38 |
| vila | starting a service should be allowed from a user with an empty password | 09:38 |
| vila | lp key should be registered in the right known_hosts file | 09:39 |
| vila | of course none of those admin tweaks could be recorded in a bzr branch :-( | 09:40 |
| mgz | but it's what we have irc logs for :) | 09:41 |
| vila | one more test including booting the slave | 09:41 |
| vila | hehe | 09:41 |
| vila | mgz: http://babune.ladeuil.net:24842/job/selftest-subset-windows/23/console | 09:42 |
| mgz | it's blue! | 09:43 |
| vila | mgz: also note that bzr has stopped complaining about lp-id | 09:43 |
| vila | *subset* ! | 09:43 |
| vila | this address the msgeditor failure | 09:43 |
| mgz | yes, but that subset would have been red. | 09:43 |
| vila | yup | 09:43 |
| vila | but that gave me 1) a simple subset to play with 2) a strong incentive to address the annoying-for-far-too-long issues :D | 09:44 |
| mgz | the remaining issues just need the same thing. | 09:45 |
| vila | mgz: note that this morning I was about to re-install windows from scratch before a let-s-try-one-more-thing urge :) | 09:45 |
| mgz | well, one's a real tough bug, but I'll find the time to finish squishing that. | 09:45 |
| vila | the trick was to find the real error behind: 'can't start the service for this user' and from there find where to click to allow a service to be launched by a user with an empty password... | 09:46 |
| vila | mgz: by the way, I tried plink too and I was close to make it work there too, but I resign once I understood that pageant can only be a starting point when it comes to forwarding ssh keys... | 09:48 |
| vila | which I reckon is because nobody can run a ssh server properly on windows | 09:48 |
| vila | The setup I ended up with, really only works for the the babune user, any other one will encounter the same kind of issue | 09:49 |
| vila | which basically are: sshd -> bzr -> ssh | 09:49 |
| vila | the ssh processes can't communicate reliably because bzr being a native app broke some cygwin assumption about who owns what including one socket/file required to communicate between the two ssh processes | 09:50 |
| vila | mgz: re-running a full test suite to see where we are now | 09:51 |
| mgz | that all sounds about right | 09:51 |
| mgz | I don't even get checkboxes, needed to use ntrights for some perms stuff for my test setup. | 09:53 |
| mgz | and manually setting HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\limitblankpassworduse | 09:54 |
| vila | don't mention guessing how this has been translated in French... | 09:55 |
| vila | I've already forgot :D | 09:55 |
| vila | and this was less than an hour ago :D | 09:55 |
| mgz | well, I'd forgotten the details too, had to go off and find the script where I'd documented what I'd done when you jogged my memory about blank password problems. | 09:56 |
| vila | too bad I didn't know about the ability to do this kind of stuff via scripts, I would have been more prone to record my tweaks this way :-/ | 09:57 |
| mgz | well, that particular script is 50% docstring and 50% after-the-fact test :) | 09:58 |
| vila | yup, I love doc strings for this kind of stiff | 09:59 |
| vila | stuff | 09:59 |
| vila | oops | 09:59 |
| mgz | "do these steps, then running this should start working" | 09:59 |
| vila | yeah, better than mere: do this stuff again next time if you're lucky enough to remember | 09:59 |
| vila | which, as mentioned above, I'm not very good at ;D | 10:00 |
| vila | mgz: I had some hope for some vbox fix in the recently release 3.0.12, but the 'lost connection during test' errors are still there :-/ | 10:08 |
| vila | 3.2.12 even | 10:09 |
| mgz | we will need more informaton on that to work out what exactly is going on. | 10:09 |
| vila | I painfully know :D | 10:13 |
| vila | mgz: wow, have you ever noticed the 'Age' column in the babune failed tests ? | 10:14 |
| mgz | yup, that's why I bugged you about the one you just fixed, because it was new-but-not-random | 10:14 |
| vila | excellent... | 10:15 |
| vila | mgz: surprising new failures in the launchpad plugin | 10:24 |
| mgz | those do look odd. | 10:25 |
| vila | mgz: surprising + 3 failures *and* surprising +3 tests... very weird | 10:25 |
| mgz | possibly related to your lp login change? | 10:29 |
| vila | failed in run #253 but not in #252 with only unrelated changes bewteen the 2 ? | 10:30 |
| mgz | sorry, as in: | 10:30 |
| mgz | <vila> lp key should be registered in the right known_hosts file | 10:30 |
| mgz | <vila> mgz: also note that bzr has stopped complaining about lp-id | 10:30 |
| vila | ooooh | 10:31 |
| mgz | I'd hope the test would be sufficiently isolated, but it may well not me. | 10:31 |
| mgz | *be | 10:31 |
| vila | bad test isolation then | 10:31 |
| vila | :) | 10:31 |
| mgz | def get_lp_login(_config=None): | 10:32 |
| mgz | if _config is None: | 10:32 |
| mgz | _config = GlobalConfig() | 10:32 |
| mgz | username = _config.get_user_option('launchpad_username') | 10:32 |
| mgz | looks dodgy. | 10:32 |
| mgz | wait... should be fine. | 10:33 |
| mgz | config is handled by the default setup? | 10:33 |
| vila | TestCaseInTempDir, so it should | 10:37 |
| vila | eerk, it isn't | 10:38 |
| mgz | I thought you told Gordon it was for his mergetools mp... | 10:39 |
| vila | no, I mean, TestCaseInTempDir should, but it seems the test manage to escape it | 10:39 |
| vila | unless.... | 10:40 |
| mgz | ah. well, it's a bug to fix, I can't repo it here unfortunately. | 10:41 |
| vila | os.environ.get('BZR_HOME') returns None ??? | 10:41 |
| vila | urgh: tests.TestCase.setUp(self) | 10:43 |
| mgz | ha! | 10:46 |
| mgz | I'd not noticed that. | 10:46 |
| mgz | one line fix to get you three passing tests again. | 10:46 |
| vila | sry, that was obscure, it's in a test class based on TestCaseInTempDir | 10:46 |
| vila | how creative we can be to defeat our own checks... | 10:46 |
| mgz | yeah, I saw it when you pasted. | 10:47 |
| mgz | it looks deliberate, so better just check the mp from barry, but seems like it should just be changed. | 10:47 |
| vila | and that fixes them all (of course) | 10:47 |
| vila | oooh, I can of recall this mp, I may even be the one that proposed the "fix" :D | 10:48 |
| mgz | karma! | 10:48 |
| vila | s/can/kind/ | 10:48 |
| vila | hihi | 10:48 |
| vila | I don't quite get how it was passing before though... | 10:49 |
| vila | raising InvalidURL because it couldn't connect maybe | 10:50 |
| mgz | https://code.launchpad.net/~barry/bzr/609186-shortcuts/+merge/37787 | 10:51 |
| mgz | ^right, that's my guess, not having a lp user was getting an earlier failure | 10:51 |
| vila | nice example of an unexpected success... | 10:52 |
| vila | mgz: how to call someone evading jail ? | 11:03 |
| mgz | escapee? there are better words I'm failing to remember | 11:04 |
| vila | dodger will do :D | 11:06 |
| fullermd | Fugitive? | 11:07 |
| vila | isolation dodger sounds better for the case at hand I think, it's not that it's running away, it's that it cleverly dodge the part we want to enforce :o) | 11:07 |
| fullermd | Evade. | 11:08 |
| mgz | that's the one. thanks fullermd. | 11:08 |
| mgz | was looking for my copy of great expectations. | 11:08 |
| fullermd | Eep. Good thing I happened by :p | 11:09 |
| vila | pfff, évadé will you ? :-D | 11:09 |
| fullermd | Poker? I hardly know 'er! | 11:09 |
| vila | but I won't use accented letters in a branch name, oh no, I've better things to do ;-p | 11:09 |
| mgz | fugitive_launchpad_plugin_tests | 11:10 |
| fullermd | Ah yes, Bon Jovi telling us how to write tests :p | 11:11 |
| mgz | I thought they were written by the man with one arm. | 11:12 |
| vila | they put several arms in servers these days | 11:13 |
| vila | fugitif can also means stealth in french | 11:14 |
| mgz | right, it's slightly emphasising the sneaking around trying to avoid recapture rather than the gaol break itself. | 11:17 |
| fullermd | I'm pretty sure it comes from Latin, so... | 11:17 |
| vila | Tempos fugit ? | 11:19 |
| fullermd | Same root. | 11:19 |
| vila | indeed | 11:20 |
| vila | time feels longer in jail, because you're closer to its roots | 11:21 |
| vila | https://code.edge.launchpad.net/~vila/bzr/684662-fugitive-launchpad-plugin-tests/+merge/42605 | 11:23 |
| vila | mgz: meh, for bzrlib.tests.blackbox.test_version.TestVersionUnicodeOutput.test_unicode_bzr_home we use get_user_encoding() for a path (BZR_HOME) ?? | 11:36 |
| vila | mgz: is that the right thing to do or a buggy test ? | 11:37 |
| mgz | yeah, and the test is a little bogus anyway which is why I've not bothered squishing it yet. | 11:37 |
| mgz | as is the actual implementation, anything using 'safe_unicode' is asking for things to blow up randomly. | 11:38 |
| vila | in config.py you mean ? | 11:39 |
| vila | I wonder if I added this to make this test pass... in anger | 11:39 |
| mgz | it was failing for me (in a different way) before that, I think related to depending on the cwd or environment | 11:41 |
| * vila tries a full run without this safe_unicode call | 11:41 | |
| vila | yeah, indeed, this test fails at a totally different place | 11:42 |
| vila | and what's the rule about env vars encoding ? It was discussed before no ? | 11:43 |
| mgz | they're in user encoding. | 11:43 |
| mgz | can't get at unicode environment with python 2 unfortunately. | 11:44 |
| vila | ha ! That was it | 11:44 |
| vila | right,single test failing | 11:44 |
| vila | so the safe_unicode may be necessary but at a different place | 11:44 |
| mgz | no. bad vila. | 11:45 |
| vila | but then the test itself is valid | 11:45 |
| vila | rhaaa, I meant user_decoding the env var :D | 11:45 |
| mgz | is never nessersary, it's just sticking a plaster on it. | 11:45 |
| mgz | yup. | 11:46 |
| vila | but waitaminute, wan't the discussion saying something different between windows and the others there ? | 11:47 |
| vila | (about env var encoding) | 11:47 |
| vila | s/wan't/wasn't/ | 11:47 |
| mgz | well, for nix you can shove any old junk in the environment block | 11:49 |
| mgz | if you do that on windows, you're liable to crash your process | 11:49 |
| vila | so the decoding should happen on windows only ? | 11:49 |
| mgz | well, depends on the abstraction, but on nix we need at least to cope with the idea that the bytes may not be in the user's encoding | 11:50 |
| vila | hmm, the problem seems so vague it's hard to address it :-/ | 11:51 |
| mgz | python 3 basically swaps having a problem on windows (with not being able to access the unicode environment) for a problem on nix (not being able to use arbitrary bytes) | 11:51 |
| mgz | which they now 'solve' with a combination of two apis for everything, and the god-awful 'surrogate escape' codec | 11:52 |
| mgz | also known as, the 'please break my xml' codec | 11:52 |
| vila | you're just adding weight to my remark :) | 11:53 |
| mgz | clear abstrations help but yeah, some of this stuff is just complex | 11:53 |
| mgz | +c | 11:53 |
| vila | basically we should start with s/os.environ.get/osutils.get_env/ or something | 11:54 |
| vila | I'm sure this will raise some eyebrows... | 11:54 |
| vila | 53 matches... | 11:55 |
| vila | wrong, 160 matches, there are os.environ[xx] uses | 11:55 |
| mgz | or just limit the apis that access the environment, and make them locale-sane depending on what we're trying to get out (a path, a flag, etc) | 11:55 |
| vila | yeah, second step :-/ | 11:56 |
| mgz | we've still got quite a lot of fiddly little bits of platform-specific code scattered around despite the osutils module | 11:56 |
| vila | but I would rather not add this if we don't need to, flag and especially 'etc' shouldn't suffer | 11:56 |
| vila | yeah :-/ | 11:57 |
| vila | I know :( | 11:57 |
| vila | right, bug #262874 | 11:59 |
| ubot5 | Launchpad bug 262874 in Bazaar "enviroment may not be in get_user_encoding() on Windows" [Medium,Confirmed] https://launchpad.net/bugs/262874 | 11:59 |
| vila | mgz: so that's not quite user encoding even :-/ | 12:00 |
| * vila lunch | 12:00 | |
| mgz | that's a semantics-and-implementation thing | 12:00 |
| mgz | have meant to close that bug out for a while. | 12:00 |
| vila | I'll defer to you then ? | 12:00 |
| mgz | basically, don't worry about that, and assume it's always in the user encoding. | 12:01 |
| vila | err, but isn't the "don't worry" attitude that led us there ? :D | 12:01 |
| mgz | not in that case :) | 12:02 |
| vila | I'll look into bzrlib.tests.test_transform.TestTreeTransform.test_rename_fails instead (after lunch ;) | 12:02 |
| mgz | what get_user_encoding does is poorly defined, and on windows we'd be better off with a raw GetACP, but that's basically what it does | 12:03 |
| mgz | which is also what the mbcs codec uses, so will in the decoding case where all bytes are in the codepage (and it doesn't have to replace invalid ones) do the same thing | 12:03 |
| mgz | bt.test_transform.TestTreeTransform.test_rename_fails is one I've got fixed vila, though you may want to add your skip_if_root thing to the top as it relies on a permissions failure | 12:06 |
| vila | mgz: meh, fixed where ? | 12:49 |
| vila | mgz: I thought the problem was to match on the error string instead of the error code those failing on the slave localized in french, but I haven't really dug so far | 12:51 |
| === vednis is now known as mars | ||
| ScottK | Is there a way to checkout/branch just part of a bzr repo? I just need http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/files/head:/scripts/ and the rest of that repository is frickin' huge. | 13:46 |
| vila | ScottK: no, you can't (yet) | 13:49 |
| ScottK | Sigh. | 13:49 |
| ScottK | Can the duration of yet be quantified at all? | 13:49 |
| vila | hardly | 13:50 |
| vila | or rather, it would be shorter to checkout the whole :-} | 13:50 |
| ScottK | Right. Just wanted to know if I should ask again next week or in 2020. | 13:53 |
| ScottK | (this isn't the first time I've missed this feature) | 13:54 |
| vila | ScottK: there are several sub parts to address: one being to transfer no more than the last revision. Otherwise getting a subtree once you have part or all of the history is something that 'views' is supposed to address | 13:55 |
| vila | ScottK: but I've never played with 'views' myself | 13:56 |
| * ScottK nods | 13:56 | |
| vila | transferring only the last revision may be worked on, I'm not sure, but it's often asked for UDD so it may happen sooner than I think | 13:57 |
| === Meths_ is now known as Meths | ||
| jam | vila: so the debuntu stuff was why Windows was failing from the TEMP paths? | 15:41 |
| vila | jam: oh ! hi ! | 16:15 |
| vila | hmm, no, the debuntu stuff revealed itself once I fixed the babune windows slave config | 16:15 |
| === tchan1 is now known as tchan | ||
| vila | jam: damn, my history is too short, waitasec | 16:16 |
| vila | <vila> mgz, jam: For the record, export BZR_SSH=openssh now works for the babune slave *including* using the ssh keys forwarded from the babune master, \o/ | 16:17 |
| vila | <mgz> for the further record, what exactly did you need to change vila? | 16:17 |
| vila | <vila> hmm | 16:17 |
| vila | <vila> the ssh server service should be started by the babune user | 16:17 |
| vila | <vila> starting a service should be allowed from a user with an empty password | 16:17 |
| vila | <vila> lp key should be registered in the right known_hosts file | 16:17 |
| vila | <vila> of course none of those admin tweaks could be recorded in a bzr branch :-( | 16:17 |
| vila | jam: so, from there, the windows slave suddenly got a launchpad login which triggered the test isolation bug | 16:18 |
| jam | vila: why does it need an lp login? | 16:18 |
| mkanat | Is there anything to guess the mime type of a file in the repository, in bzrlib? | 16:18 |
| vila | jam: to get rid of some annoying warnings and use the smart server instead of http | 16:19 |
| jam | mkanat: I don't believe there is mime awareness inside bzrlib | 16:20 |
| mkanat | jam: Okay. | 16:20 |
| jam | vila: is that for the test suite itself? or for other stuff | 16:20 |
| mkanat | All I really would want was something that would check the first few bytes of a file in the repo and guess its mime type. | 16:21 |
| jam | I'm fine w/ other stuff, but I'd like to understand what the *test suite* is trying to do | 16:21 |
| jam | mkanat: to get the first few bytes basically gets all of them | 16:21 |
| jam | so you may as well get the text and send it to "file" | 16:21 |
| mkanat | jam: Fair enough. I'm trying to avoid that, though. | 16:21 |
| mkanat | jam: This is for loggerhead, and I want to return a generator that can stream the file, but I also want to have reliably mime-type guessing. I'm going to be doing it based on the file name, but still. | 16:22 |
| jam | mkanat: do what you feel is best, just letting you know that we don't extract partial content | 16:22 |
| mkanat | jam: Okay. | 16:22 |
| jam | extracting content is probably a O(2x size-of-fulltext deal) | 16:23 |
| jam | one for the delta buffer, one for the final text | 16:23 |
| mkanat | Sure, I just don't want it in memory if I can avoid it, as much as possible. | 16:23 |
| jam | (and 0.5 for the compressed content of the delta buffer) | 16:23 |
| === beuno is now known as beuno-lunch | ||
| jam | mkanat: 'as much as possible' would probably mean extracting it, writing it to a temp file, streaming from that | 16:24 |
| mkanat | jam: Well, I was just going to return an iter_bytes or whatever it's called. | 16:24 |
| jam | mkanat: that just extracts the whole thing, and probably caches all the intermediate stuff until its done | 16:24 |
| vila | jam: both, it makes the pulls faster and it gives access from the slave to the master for planned features | 16:24 |
| mkanat | jam: Okay. But will that always be the case? I mean, if bzr improves, I'll get the improvement there too. | 16:25 |
| jam | mkanat: I would not expect us to change that for a long time | 16:25 |
| vila | jam: including: automated updates for dependencies, upload of artifacts from slave to master, etc | 16:25 |
| mkanat | jam: Okay, well, what about the big-file work? | 16:25 |
| jam | mkanat: there is one proposal which might break up big content into smaller chunks, but that is goingto complicate whatever you try to do anyway | 16:25 |
| jam | vila: all not test-suite related, afaict. I think it is great that you have it. My concern is why it affected the *test suite* | 16:26 |
| mkanat | jam: But if it's just an iter, it shouldn't complicate anything. | 16:26 |
| vila | jam: the test suite doesn't require ssh access, but the slave get its branches from lp (so far). If you look at some old windows runs, you'll notice the lp-related warning | 16:26 |
| mkanat | jam: I suppose the problem is that you have to build the revision text before you can stream it? | 16:27 |
| jam | mkanat: well iter_bytes *today* is just [content_string] | 16:27 |
| jam | it might change in the future, but that is pretty unlikely at this point | 16:27 |
| jam | vila: sure. Though you said "I fixed the login stuff, and suddenly the test started failing" | 16:29 |
| vila | jam: yes, that's what happened | 16:29 |
| jam | vila: hence my concern why external config is affecting the test suite | 16:29 |
| vila | jam: you didn't read the fix don't you ? | 16:30 |
| vila | jam: the test was getting a launchpad login by accessing the local bazaar.conf in $HOME instead of the empty one we create under TMP | 16:30 |
| jam | vila: ah, ok. So the fix should actually remove the dependency. I did read the fix | 16:31 |
| vila | which dependency ? | 16:32 |
| jam | vila: the existing code accidentally dependend on the users config because it escaped isolation. You noticed the bug because of changing the user config, which prompted you to fix the dependency. Future test runs should be properly isolated from user config. \o/ | 16:32 |
| vila | but they are as long as they use TestCaseInTempDir and not TestCase | 16:33 |
| vila | these ones are a bit special as in this case they were unexpected successes but I felt it wasn't worth the time to guard against that | 16:33 |
| vila | I think I mentioned in the cover letter that they were probably succeeding before because InvalidURL was being raised earlier (while attempting to connect without a proper lp login or something) | 16:35 |
| === deryck is now known as deryck[lunch] | ||
| mkanat | Is there a way to get the size of the content that iter_file_bytes is going to return, or do I just have to get all the bytes and then do len(content)? | 16:37 |
| jam | mkanat: tree.inventory[file_id].text_size | 16:38 |
| mkanat | jam: Awesome, thank you. :-) | 16:38 |
| hazmat | when using bzr-pipeline, and switching pipes is there a way a hook can be invoked, i often have *.pyc files that end up cluttering directories that are added and removed, which generates spurious conflicts when navigating up/down the pipe | 16:59 |
| mkanat | mwhudson: Do you know what the motivation was behind choosing SimpleTAL for loggerhead? | 17:17 |
| === deryck[lunch] is now known as deryck | ||
| === beuno-lunch is now known as beuno | ||
| mgz | vila: that test will start passing when bug 273978 is fixed, which I have a branch for (unproposed as yet, still needs work) | 18:09 |
| ubot5 | Launchpad bug 273978 in Bazaar "UnicodeDecodeError when strerror is not ascii" [Low,Confirmed] https://launchpad.net/bugs/273978 | 18:09 |
| vila | mgz: haaa, good :) Oh yeah, I remember now ! | 18:10 |
| vila | EOD here (and invited by friends so I'll may poke here far later but that's rather unsure ;) | 18:11 |
| mgz | it's one of my top things to do before 2.3 now I've sorted the testing unicode stuff, just need a space to bash it in. | 18:11 |
| mgz | food for me too. | 18:13 |
| mkanat | Wow, bzr really *is* fast, when you use the API right. It's pretty remarkable sometimes. | 18:33 |
| mkanat | I'm doing everything needed to get a file out of the system and send it to the client in 0.05 seconds or less. | 18:33 |
| jam | mkanat: simpletal was the fastest reasonable engine at the time, and was used elsewhere, IIRC | 18:48 |
| mkanat | jam: Ah, okay. | 18:48 |
| mkanat | Is that what Launchpad is using also, or is it using something else? | 18:49 |
| jam | I think there was a push at one point to use something like Cheetah, which compiles the same syntax into python bytecode | 18:49 |
| mkanat | jam: Yeah, I was thinking Mako actually. | 18:49 |
| jam | mkanat: IIRC, simpletal is zope's engine pulled out | 18:49 |
| jam | and LP is built on zope | 18:49 |
| mkanat | jam: Ahh, okay. | 18:49 |
| mkanat | So there's also shared expertise. | 18:49 |
| jam | right, though using the same syntax with a faster engine would be fine | 18:50 |
| mkanat | It's fine, I don't have any problems with SimpleTAL right now. I mean, no major problems. The templates would be cleaner in Mako. | 18:50 |
| jam | I think we wanted to avoid a different TAL | 18:50 |
| jam | (template language, if that is actually a bad acronym) | 18:50 |
| mkanat | Yeah. | 18:50 |
| beuno | mkanat, jam, we went with simpletal because it was fast, and used TAL, which is what Launchpad used, so we where familiar with it | 18:52 |
| mkanat | Okay. I think TAL has some nice advantages, but I wouldn't be super-excited about designing a large system with it. Although I suppose you guys did with LP. :-) | 18:52 |
| mkanat | I like that it forces you to have valid HTML that at least has closing tags and so on. | 18:53 |
| mkanat | And I like the convenience of putting stuff in attributes. | 18:53 |
| mkanat | But I think that after a while, it becomes very difficult to read, with everything in the attributes. | 18:54 |
| mkanat | Although that does encourage you to keep the templates simple. | 18:54 |
| mkanat | It's *very* hard to see the logic flow in a large template with a lot of tal:condition. | 18:55 |
| jam | beuno, mkanat: sites like this http://nick.zoic.org/2009/07/29/templates-fugit-3/ doen't make me think simpletal is all that fast. :) | 18:58 |
| jam | or this: http://nick.zoic.org/2010/04/ | 18:59 |
| jam | though I think that is the same guy | 18:59 |
| mkanat | jam: Yeah, another reason I like Mako. :-) | 18:59 |
| mkanat | Besides the fact that it's the best template language I've ever used, possibly tied with the Template Toolkit. | 18:59 |
| mkanat | Well, I think I like Mako more in some ways, though. | 18:59 |
| beuno | jam, at the time, simpletal was as fast as the other engines we tried out | 18:59 |
| beuno | I implemented loggerhead in a few different engines | 18:59 |
| beuno | and our benchmarks where more or less the same or worst | 19:00 |
| beuno | so we went with that for familiarity | 19:00 |
| beuno | but, this was... 3 years ago? | 19:00 |
| mkanat | Yeah, I wouldn't imagine that the template language is a primary performance limiter on LP in any case. | 19:00 |
| jam | beuno: I can imagine that it would depend a lot on what you were doing with the template | 19:02 |
| jam | I do remember the discussions (though not in detail() | 19:02 |
| mkanat | Three years ago, I don't think Mako even existed. | 19:03 |
| maxb | Does anyone know, did Savannah ever get a helper to help with Loggerhead? | 19:08 |
| mkanat | maxb: Not that I know of. | 19:09 |
| jam | mkanat, beuno: My email archives show Mako being mentioned back in 2008-07-09 and also another 2008-07-10 proposal to use SimpleTAL | 19:12 |
| mkanat | jam: I think at that time Mako would have been brand new. | 19:13 |
| jam | with mwhudson saying: If we could get the same perf out of genshi, I would prefer it, | 19:13 |
| jam | and that simpletal is the "fastest tree-based engine" | 19:13 |
| jam | (from beuno) | 19:13 |
| jam | so the "Tree-based" was probably a familiarity factor | 19:13 |
| beuno | right, I did test genshi, and it was slower | 19:13 |
| beuno | yes, mwhudson really wanted something tree-based | 19:13 |
| jam | he seemed pretty happy with genshi, except the perf sucked :) | 19:18 |
| jam | mkanat: anyway, I don't think there is a strict requirement for simpletal, but there should be a strong reason to switch | 19:18 |
| jam | since it involves re-building all the dependencies, etc. | 19:18 |
| mkanat | jam: Okay. Yeah. | 19:18 |
| jam | mkanat: (so if you find that a page request is 0.1s bzrlib time, and 10s simpletal time, and mako would make that 0.01s mako time, that would be motivating. If it makes it 9s mako time, not so much, or if it is 10s bzrlib time, and 0.1s simpletal vs 0.00001s mako, etc) | 19:26 |
| mkanat | jam: Yeah, for sure. | 19:26 |
| mkanat | jam: I think what I would like about Mako would be the development advantages more than the speed advantages. | 19:26 |
| jam | well, you are currently the primary dev on it, but you won't always be :) | 19:30 |
| jam | Looking at the differences, I do find TAL to be a bit strange | 19:30 |
| jam | the "replace the current <> with this content" is odd to me | 19:30 |
| * mkanat nods. | 19:30 | |
| jam | but then again here: http://www.makotemplates.org/ | 19:30 |
| jam | having: | 19:30 |
| jam | % for name in row: <td>${name}</td>\ % endfor | 19:30 |
| jam | is also really odd | 19:30 |
| mkanat | But much more readable. | 19:31 |
| jam | (lines with % are python control, but they output the content of lines that aren't %, etc) | 19:31 |
| jam | goes back to why I didn't like PHP | 19:31 |
| mkanat | Yeah, but that quality is pretty much extant in all template languages. | 19:31 |
| jam | I was never quite sure what got put out the pipe and what didn't | 19:31 |
| mkanat | I mean, that's pretty much the definition of a template language. | 19:31 |
| jam | never quite sure what was wrong with """%(data)s""" % {'data': 'foo'} | 19:31 |
| mkanat | Well, a lot of things. | 19:32 |
| mkanat | One of the cool things that Mako has that no other template language has (that I know of) is inheritance. | 19:34 |
| lifeless | mkanat: I don't mind if you change the template language but... | 19:35 |
| lifeless | mkanat: it will make it harder for lp devs to debug and fix things. | 19:35 |
| mkanat | lifeless: Yeah. | 19:35 |
| mkanat | lifeless: I have no immediate plans to make any major changes like that. | 19:35 |
| jam | mkanat: I do seem to remember that rendering time was pretty long for stuff like the 'changes' page. about 50/50 IIRC | 19:37 |
| mkanat | jam: That wouldn't surprise me, I haven't tested that yet. | 19:37 |
| mkanat | jam: Sometimes rendering times are long because we are sending a generator from bzr though, too. | 19:37 |
| jam | mkanat: possible, though the bits I saw tend to list(bzr_stuff) before passing them over. | 19:42 |
| jam | anyway, glad you're working on it rather than me ATM. | 19:42 |
| mkanat | jam: :-) | 19:42 |
| jam | also, glad to see you working on it, period | 19:42 |
| jam | you went quiet for a bit, and I wasn't sure what was going on | 19:42 |
| mkanat | jam: I'm really glad you did the history_db stuff, though--I think for the most part that would have been much too high a level of bzr wizardry for me at this point. :-) | 19:42 |
| mkanat | jam: Yeah, some of it was getting contract details worked out, and then some of it was scheduling issues. | 19:43 |
| jam | mkanat: thanks, just need to actually get it deployed so it doesn't sit there languishing | 19:43 |
| mkanat | jam: Yeah, I want to deploy it more or less once we're ready for 2.0. | 19:43 |
| mkanat | jam: In any case, now I'm pretty active on loggerhead, and though my actions are somewhat limited, there's still a lot of stuff I'm planning to do. | 19:44 |
| === gthorslund_ is now known as gthorslund | ||
| achiang | hello, i'm trying to help a non-technical friend (she is a scientist, not a programmer) use bzr. she's created an LP account, downloaded bzr for windows, managed to pull source from LP, made a change, and committed it locally | 21:19 |
| achiang | now she is having issues pushing the branch back to LP | 21:19 |
| achiang | the error is: | 21:20 |
| achiang | Run command: bzr push "bzr push lp:~lindsayvail/streamflow/newheader\n" | 21:20 |
| achiang | bzr: ERROR: Unsupported protocol for url "bzr push lp:~lindsayvail/streamflow/newheader | 21:20 |
| achiang | " | 21:20 |
| achiang | i guess that's coming from the windows gui tool, which i've never used | 21:20 |
| achiang | any hints? | 21:20 |
| achiang | ah, she reports that the command line is working for her | 21:20 |
| achiang | still, i'd like to know what we might be doing wrong in the windows tool. | 21:21 |
| jam | achiang: it at least sounds like she didn't install the lp plugin | 21:45 |
| achiang | jam: hm, didn't realize that was a required step | 21:45 |
| achiang | jam: thanks for the clue | 21:45 |
| jam | achiang: it is part of the installer | 21:45 |
| jam | it can be disabled, defaults to on | 21:45 |
| jam | achiang: if she was able to branch from the begininng from an lp: url, then that probably isn't it | 21:46 |
| jam | because it would work both ways | 21:46 |
| achiang | jam: interesting. i don't think she would have turned it off | 21:46 |
| jam | the other option | 21:46 |
| jam | is that she hasn't informed bzr of what account to use on LP | 21:46 |
| jam | I don't remember the gui way to do that | 21:46 |
| jam | the command line is "bzr launchpad-login <lpusername>" | 21:46 |
| achiang | nod | 21:48 |
| jam | achiang: I would have thought that would give more "unable to push to http://..." but it could be a secondary error | 21:48 |
| svz90 | Hi. I had a quick question about bzr's ssh/sftp module. Is it possible to specify a custom ssh identity file (like with ssh -i somefile)? | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!