[00:03] hello, can someone explain what i'm doing wrong here? http://pastebin.ubuntu.com/539211/ [00:03] trying to make it so that my streamflow project uses my personal email, not my work email [00:03] according to the help i found on google, that syntax i used should work... [00:04] achiang: what file is that top section from? [00:04] i think it needs to be ~/.bazaar/locations.conf, not ~/.bazaar/bazaar.conf [00:04] mwhudson: ~/.bazaar/bazaar.conf [00:04] mwhudson: hm, interesting [00:04] i will try again [00:05] mwhudson: yes, that was it, thank you [00:06] achiang: np [00:06] mwhudson: the problem was entirely mine. i read this page too fast -- http://wiki.bazaar.canonical.com/ConfiguringBzr [00:06] hi mwh, achiang [00:06] the documentation clearly says locations.conf, and i misread it [00:07] so your documentation is good, i am just dumb. :) [00:07] poolie: hi [00:45] $ bzr resolve --take-this .bzrignore [00:45] 0 conflict(s) resolved, 1 remaining [00:45] erm, what? [00:45] (yes, .bzrignore is conflicted) [00:45] text conflicted, that is [00:49] maxb: :( [00:53] maxb: bzr resolve --take-this .bzrignore.THIS ? [00:55] maxb, iirc what vila said, it does not mark it as resolved [00:55] it should [00:55] we should distinguish "do this to the file" from "mark the conflict as solved" [01:44] hey [01:44] how do I set append only for an existing branch on LP? [01:52] thumper: by editing the branch.conf file, I think :( [01:53] what? [01:53] that's a bit primitive [01:53] thumper: I expect vila's config work will provide UI for this fairly soon [01:53] spiv: what do I need to add? [01:53] I'm sure hitchhiker can work wonders [01:54] append_revisions_only = True [01:54] Or open the branch object and call br.set_append_revisions_only(True) [02:10] thumper: thanks for your mail about apis, i'm replying [02:10] spiv, maybe we should pair together more [02:10] i was thinking of buying a desktop rather than headset mike [02:23] poolie: Any hope of getting my loggerhead changes pushed to LP? [02:23] Or approved, at least. [02:23] good question! [02:23] did i review but not mark them approved? [02:23] or... there are probably more still unreviewed? [02:24] poolie: Ah, I merged them into loggerhead, but the LP branch push MP is still waiting a review. [02:28] Hey, I have a workflow hiccup with bzr that I am wondering if you guys can shed some light on. [02:28] I frequently encounter diverged branches that I don't really expect [02:29] this is mainly in my 'personal preferences' repository, which I keep on several machines [02:29] 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] commit locally [02:30] poolie: cool [02:30] then later I make changes to the repository on my desktop, push those changes [02:30] and then, 30 seconds before I go somewhere, I do a quick 'bzr pull' on my laptop [02:31] 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] glyph: Ah, you have to do a "bzr merge" in that situation instead. [02:31] 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] More importantly, I have to do something interactive [02:32] glyph: Perhaps you would be interested in 'bzr merge --pull' (pull if you can, otherwise merge) [02:32] maxb: Hmm, maybe that is what I want [02:32] although [02:32] Of course, you still need to commit and push [02:33] 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:35] Well, it's not the greatest of UIs, but that kind of already happens (except for the helpful bit) [02:36] haha [02:36] maxb: is that bzr's motto? [02:36] maxb: 'that already works, except for the helpful bit' [02:36] The not-actually-pulled head will be stored in the local repository and visible in 'bzr heads --dead' [02:36] you would be able to merge it by revision-id later [02:36] woah [02:36] that's pretty awesome [02:37] so the network I/O actually _does_ happen? [02:38] sure, it's not just pretending :-) [02:38] well, I knew _some_ did [02:38] I didn't realize it actually pulled all of the revs though [02:40] so, how about this [02:41] if I make a no-tree branch in my branch and then only ever pull into it [02:41] then I can just do 'cd upstream; bzr pull' [02:41] and then 'cd ..; bzr merge --pull upstream' [02:41] when I have a moment to sit and merge later, but potentially no network I/O [02:42] hmm, if I do 'bzr get . upstream', it works, but it doesn't appear to use the working directory as a shared repository [02:43] 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] do I have any option here? [02:45] erm, possibly [02:46] let me test something.... [02:47] 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:49] maxb: hmm [02:49] maxb: maybe I don't need to do that [02:50] now that I'm looking at the output of heads --dead, I can see that it's basically doing what I want [02:50] yeah [02:50] okay this is cool [02:51] maxb: thanks for the info [02:57] poolie: it would be interesting to try pairing more [02:57] poolie: I'd have to have a bit of a think about headsets etc. [02:57] perhaps we should just meet up and actually pair? [02:58] 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] or or things you have in train [03:06] so, now I think I know how to phrase my request [03:06] 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:07] if 'bzr pull' fails [03:07] or "if the branches have diverged" [03:07] it looks like 'push' actually fixes the divergent revisions too? this is really neat! [03:07] push actually _pulls_ the divergent revisions [03:15] glyph: how precisely would you define "last"? [03:15] merge --last is an interesting concept. It's roughly equivalent to .git/FETCH_HEAD [03:15] glyph: you mean the head most recently added to the repo? [03:16] spiv: I *think* that's what I mean, but I don't understand those terms perfectly, so, to be explicit: [03:17] 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] 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 :) [04:12] glyph: so the trick is finding the right diverged tip [04:13] glyph: maybe you have other tips from doing "bzr merge; bzr revert", or from "bzr uncommit". === BasicPRO is now known as BasicOSX [05:47] spiv: well, this is why I phrased my requirement that way. [05:48] 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:53] 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." [06:04] 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:05] is it simply `bzr diff -c revno > filename.patch` ? [06:07] and and then `bzr merge filename.patch`? [06:08] hmm, that didn't work [06:09] dmuir: I think you need to use the gnu "patch" command to apply the batch [06:10] it won't handle renames or binary files correctly however [06:10] hmm, ok [06:11] dmuir: give this a try? http://www.cuberick.com/2009/02/merge-bazaar-repositories-with-no.html [06:14] dmuir: 'bzr send' [06:15] peitschie: woah, that is rad. [06:16] hmm, if I understand the cuberick trick, I'm basically cherrypicking the tree as a whole? [06:17] I'm still getting a bunch of conflicts, but I think they're all fairly straight forward. [06:17] dmuir: sounds about right [06:18] glyph: I think send wants to provide a bundle, which pretty much requires a common ancestor? [06:19] hmm, send crashed on me [06:27] bzrtools's patch seems to do the job reasonably well [06:40] glyph: ok, I'd call that option --last-pull in that case. [06:45] spiv: really, I just want it to be the default behavior of 'merge' :) [06:47] glyph: have a local mirror of the source branch, and have that mirror associated as the parent branch, and you'd have that ;) [06:57] spiv: any better way to do the branch-and-shared-repository thing? [06:58] it would just be handy to have the local mirror be an empty dir called 'upstream' ;) [07:27] 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] possible with GIT? [07:29] this isn't the git channel [07:29] Err, I mean Bazaar. You see I'm evaluating the various Source control [07:29] you could store it in a bzr branch and reference it from all your projects [07:29] systems. [07:29] by a lnk, or some other means [07:29] bzr won't automatically update every checkout of it [07:30] 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] glyph: although it might be nicer and simpler to use the bzr-colo plugin [07:31] Thanks, I'll look up branch and link benhaviour [07:33] hi all [07:35] pingeling about https://code.edge.launchpad.net/~vila/bzr/638451-malformed/+merge/41759 [07:46] hi there vila [07:46] poolie: hey ! [07:47] sorry vila, i really wanted to do that today [07:47] didn't get to it [07:47] :/ [07:47] 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:48] * poolie looks quickly [07:48] i have to go soon [07:48] poolie: yeah, no worries, I've seen a couple of interesting mails from you :) [07:49] does it actually resolve things? [07:49] i mean, does it mark the conflict resolved? [07:49] oh yes [07:49] it looks basically ok [07:49] so, weak +1 if you're confident to merge it [07:49] now i have to go; have a good day! [07:49] and weekend [07:49] poolie: you too ! and thanks ! [07:50] too slow ;) [07:57] 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] 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? [08:00] 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:01] 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] UnhappyVssUser: because if you revert to a previous revision you don't want to revert this file too [08:02] UnhappyVssUser: or not ? [08:04] UnhappyVssUser: by the way, your previous msgs were truncated making them a bit unclear [08:13] vila: Sorry for the truncated texts. Opera browser makes that (if you meant the two lines). [08:14] UnhappyVssUser: the first one ends with 'It is poss' and the second starts with 'class files and' [08:18] 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:19] I'm not laughing, I feel your pain :) [08:19] 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:20] right, so that's a fundamental difference [08:20] with bzr you don't version files, you version trees [08:21] Well, but what do you do if you want to have the same file on multiple places? [08:22] Don't tell me you edit all of them manually!!! [08:22] the question is whether you want this file to follow the history of its containing tree or not [08:23] UnhappyVssUser: if you revert a tree to a previous revision, do *you* want this file to also revert to this previous revision ? [08:24] yes, it should also revert to the previous revision ("label") [08:25] I'm looking up the "tree" and what it represents in VSS....if there is such a thing [08:25] 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:26] UnhappyVssUser: I suspect a tree is really a label: i.e. the set of (file, revision) that happen to carry this label [08:27] .. but may be not, (how would updates of the shared files propagate to other labels ?) [08:27] I found it in bazaar doc: http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-vss-users.html [08:27] A "label" seems to be a tag [08:29] UnhappyVssUser: right, this page says that Share is N/A [08:29] UnhappyVssUser: surely the person that wrote it knows VSS (I don't, I *guess* it's closer to CVS than to bzr) [08:30] Well, if you're going to insult CVS... [08:31] fullermd: hey ! [08:31] I rarely insult tools anymore these days, they tend to just ignore me when I do that [08:32] They ignore me too, but it's still very cathartic to scream at them. [08:33] ... another reason is that ISTM, these insults tend to bounce back at me for trusting the tools too much :-D [08:41] 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:43] 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] someone help me ? [08:44] scmproj ! [08:44] UnhappyVssUser: http://doc.bazaar.canonical.com/plugins/en/ [08:46] 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] vila: Thanks for the link. More to read... [08:47] vila: I thank you very much. Very helpful. I'll check the plugins... [08:47] UnhappyVssUser: you're welcome [08:47] have a good day (The boss appeared at my office ...uh) [08:48] He does not know of his bazaar luck, yet [08:49] UnhappyVssUser: quick ! Bring up your facebook page ! Enough of this productivity-enhancing tools discussions !! [08:49] lol [08:49] :) [08:49] But honestly, this is his thinking [08:50] 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:51] fullermd: by the way, just curious, how would you address this 'shared file' issue in CVS ? [08:51] UnhappyVssUser: Yeah, I know the feeling :-/ [08:51] fullermd: CVSROOT/modules tinkering ? [08:51] I s'pose you could "ln -s /some/other/repo/foo,v ." [08:52] fullermd: naaah, on windows man, no funny symlinks... [08:52] Well, you wouldn't be hosting a CVS repo on windows in the first place... [08:52] fullermd: pff, cheater :D [08:53] Man, if we're running CVS, cheating is de rigeur :p [08:53] LOL [08:53] good to know I can use 'de rigueur' with English people ;) [08:54] Oh, did French borrow that phrase from English too? ;> [08:55] something like that certainly ;D [09:17] ha ! window is easy, just one click is enough ! [09:17] The trouble is to find which one... [09:37] 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] for the further record, what exactly did you need to change vila? [09:37] hmm [09:38] the ssh server service should be started by the babune user [09:38] starting a service should be allowed from a user with an empty password [09:39] lp key should be registered in the right known_hosts file [09:40] of course none of those admin tweaks could be recorded in a bzr branch :-( [09:41] but it's what we have irc logs for :) [09:41] one more test including booting the slave [09:41] hehe [09:42] mgz: http://babune.ladeuil.net:24842/job/selftest-subset-windows/23/console [09:43] it's blue! [09:43] mgz: also note that bzr has stopped complaining about lp-id [09:43] *subset* ! [09:43] this address the msgeditor failure [09:43] yes, but that subset would have been red. [09:43] yup [09:44] 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:45] the remaining issues just need the same thing. [09:45] 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] well, one's a real tough bug, but I'll find the time to finish squishing that. [09:46] 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:48] 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] which I reckon is because nobody can run a ssh server properly on windows [09:49] 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] which basically are: sshd -> bzr -> ssh [09:50] 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:51] mgz: re-running a full test suite to see where we are now [09:51] that all sounds about right [09:53] I don't even get checkboxes, needed to use ntrights for some perms stuff for my test setup. [09:54] and manually setting HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\limitblankpassworduse [09:55] don't mention guessing how this has been translated in French... [09:55] I've already forgot :D [09:55] and this was less than an hour ago :D [09:56] 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:57] 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:58] well, that particular script is 50% docstring and 50% after-the-fact test :) [09:59] yup, I love doc strings for this kind of stiff [09:59] stuff [09:59] oops [09:59] "do these steps, then running this should start working" [09:59] yeah, better than mere: do this stuff again next time if you're lucky enough to remember [10:00] which, as mentioned above, I'm not very good at ;D [10:08] 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:09] 3.2.12 even [10:09] we will need more informaton on that to work out what exactly is going on. [10:13] I painfully know :D [10:14] mgz: wow, have you ever noticed the 'Age' column in the babune failed tests ? [10:14] yup, that's why I bugged you about the one you just fixed, because it was new-but-not-random [10:15] excellent... [10:24] mgz: surprising new failures in the launchpad plugin [10:25] those do look odd. [10:25] mgz: surprising + 3 failures *and* surprising +3 tests... very weird [10:29] possibly related to your lp login change? [10:30] failed in run #253 but not in #252 with only unrelated changes bewteen the 2 ? [10:30] sorry, as in: [10:30] lp key should be registered in the right known_hosts file [10:30] mgz: also note that bzr has stopped complaining about lp-id [10:31] ooooh [10:31] I'd hope the test would be sufficiently isolated, but it may well not me. [10:31] *be [10:31] bad test isolation then [10:31] :) [10:32] def get_lp_login(_config=None): [10:32] if _config is None: [10:32] _config = GlobalConfig() [10:32] username = _config.get_user_option('launchpad_username') [10:32] looks dodgy. [10:33] wait... should be fine. [10:33] config is handled by the default setup? [10:37] TestCaseInTempDir, so it should [10:38] eerk, it isn't [10:39] I thought you told Gordon it was for his mergetools mp... [10:39] no, I mean, TestCaseInTempDir should, but it seems the test manage to escape it [10:40] unless.... [10:41] ah. well, it's a bug to fix, I can't repo it here unfortunately. [10:41] os.environ.get('BZR_HOME') returns None ??? [10:43] urgh: tests.TestCase.setUp(self) [10:46] ha! [10:46] I'd not noticed that. [10:46] one line fix to get you three passing tests again. [10:46] sry, that was obscure, it's in a test class based on TestCaseInTempDir [10:46] how creative we can be to defeat our own checks... [10:47] yeah, I saw it when you pasted. [10:47] it looks deliberate, so better just check the mp from barry, but seems like it should just be changed. [10:47] and that fixes them all (of course) [10:48] oooh, I can of recall this mp, I may even be the one that proposed the "fix" :D [10:48] karma! [10:48] s/can/kind/ [10:48] hihi [10:49] I don't quite get how it was passing before though... [10:50] raising InvalidURL because it couldn't connect maybe [10:51] https://code.launchpad.net/~barry/bzr/609186-shortcuts/+merge/37787 [10:51] ^right, that's my guess, not having a lp user was getting an earlier failure [10:52] nice example of an unexpected success... [11:03] mgz: how to call someone evading jail ? [11:04] escapee? there are better words I'm failing to remember [11:06] dodger will do :D [11:07] Fugitive? [11:07] 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:08] Evade. [11:08] that's the one. thanks fullermd. [11:08] was looking for my copy of great expectations. [11:09] Eep. Good thing I happened by :p [11:09] pfff, évadé will you ? :-D [11:09] Poker? I hardly know 'er! [11:09] but I won't use accented letters in a branch name, oh no, I've better things to do ;-p [11:10] fugitive_launchpad_plugin_tests [11:11] Ah yes, Bon Jovi telling us how to write tests :p [11:12] I thought they were written by the man with one arm. [11:13] they put several arms in servers these days [11:14] fugitif can also means stealth in french [11:17] right, it's slightly emphasising the sneaking around trying to avoid recapture rather than the gaol break itself. [11:17] I'm pretty sure it comes from Latin, so... [11:19] Tempos fugit ? [11:19] Same root. [11:20] indeed [11:21] time feels longer in jail, because you're closer to its roots [11:23] https://code.edge.launchpad.net/~vila/bzr/684662-fugitive-launchpad-plugin-tests/+merge/42605 [11:36] mgz: meh, for bzrlib.tests.blackbox.test_version.TestVersionUnicodeOutput.test_unicode_bzr_home we use get_user_encoding() for a path (BZR_HOME) ?? [11:37] mgz: is that the right thing to do or a buggy test ? [11:37] yeah, and the test is a little bogus anyway which is why I've not bothered squishing it yet. [11:38] as is the actual implementation, anything using 'safe_unicode' is asking for things to blow up randomly. [11:39] in config.py you mean ? [11:39] I wonder if I added this to make this test pass... in anger [11:41] 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:42] yeah, indeed, this test fails at a totally different place [11:43] and what's the rule about env vars encoding ? It was discussed before no ? [11:43] they're in user encoding. [11:44] can't get at unicode environment with python 2 unfortunately. [11:44] ha ! That was it [11:44] right,single test failing [11:44] so the safe_unicode may be necessary but at a different place [11:45] no. bad vila. [11:45] but then the test itself is valid [11:45] rhaaa, I meant user_decoding the env var :D [11:45] is never nessersary, it's just sticking a plaster on it. [11:46] yup. [11:47] but waitaminute, wan't the discussion saying something different between windows and the others there ? [11:47] (about env var encoding) [11:47] s/wan't/wasn't/ [11:49] well, for nix you can shove any old junk in the environment block [11:49] if you do that on windows, you're liable to crash your process [11:49] so the decoding should happen on windows only ? [11:50] 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:51] hmm, the problem seems so vague it's hard to address it :-/ [11:51] 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:52] which they now 'solve' with a combination of two apis for everything, and the god-awful 'surrogate escape' codec [11:52] also known as, the 'please break my xml' codec [11:53] you're just adding weight to my remark :) [11:53] clear abstrations help but yeah, some of this stuff is just complex [11:53] +c [11:54] basically we should start with s/os.environ.get/osutils.get_env/ or something [11:54] I'm sure this will raise some eyebrows... [11:55] 53 matches... [11:55] wrong, 160 matches, there are os.environ[xx] uses [11:55] 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:56] yeah, second step :-/ [11:56] we've still got quite a lot of fiddly little bits of platform-specific code scattered around despite the osutils module [11:56] but I would rather not add this if we don't need to, flag and especially 'etc' shouldn't suffer [11:57] yeah :-/ [11:57] I know :( [11:59] right, bug #262874 [11:59] Launchpad bug 262874 in Bazaar "enviroment may not be in get_user_encoding() on Windows" [Medium,Confirmed] https://launchpad.net/bugs/262874 [12:00] mgz: so that's not quite user encoding even :-/ [12:00] * vila lunch [12:00] that's a semantics-and-implementation thing [12:00] have meant to close that bug out for a while. [12:00] I'll defer to you then ? [12:01] basically, don't worry about that, and assume it's always in the user encoding. [12:01] err, but isn't the "don't worry" attitude that led us there ? :D [12:02] not in that case :) [12:02] I'll look into bzrlib.tests.test_transform.TestTreeTransform.test_rename_fails instead (after lunch ;) [12:03] 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]