[00:01] poolie, is there a specific test (or test type) you recommend i look at as a pattern for creating the large-file-add test? is the shell-like interface appropriate? [00:02] hi grid, i think that would be a reasonable way to do it === krow_ is now known as krow [00:06] ok, i suppose it makes sense to add it to blackbox/test_add.py even === med is now known as med_out [00:13] so, pros and cons [00:14] using shell-like tests: [00:14] - tests most of the stack integrated together [00:14] - therefore catches integration bugs [00:14] - and also is slower [00:15] - is a somewhat less precise mechanism for setting things up and evaluating them [00:16] - requires less prior knowledge [00:16] so... for a first patch overall it's pretty good [00:16] if you wanted to cover dozens of different cases probably using api tests would be better [00:58] ok thanks. tomorrow (fri) is the first chance i'll get to write some code so i'll see how it goes, maybe have some questions. [01:17] cool [01:17] i hope you enjoy it, ask here on the list if you want [04:00] Hi [04:30] Suppose I have some revision X and it's ruining my life, how do I revert just those changes? [04:40] TiffanyAngel87: and X is not the latest revision? [04:40] AfC: correct [04:41] TiffanyAngel87: you have to commit the "reverse" of what that revision introduced. [04:41] TiffanyAngel87: you do that by using merge, backwards: [04:41] if X is 47 [04:41] say [04:41] then [04:41] $ bzr diff -r 46..47 [04:42] shows you the change set introduced by (resulting in) that revision (state) [04:42] TiffanyAngel87: right? [04:42] with you so far [04:43] so, to get rid of it, you merge the inverse. You can first see that with [04:43] jelmer, hi? [04:43] $ bzr diff -r 47..46 [04:43] (note the + and - inverted) [04:43] ohhhh [04:43] but to do it, use merge [04:43] then patch -p0? [04:43] no merge: [04:43] $ bzr merge -r 47..46 [04:43] [that's implicitly "from this branch"] [04:43] $ bzr merge -r 47..46 /path/to/branch [04:44] I'll give it a try. Thanks! [04:44] would have pulled that delta from somewhere else [04:44] the reverse merge is effectively the same as the diff and patch, right? [04:44] I'll let someone else answer that; my belief is that there's more to it than that [04:45] ie, merge can be (dramatically) smarter about base revisions, ancestors, etc [04:45] There's a reason we don't throw history away in Bazaar land [04:45] cherrypicks don't carry their history though, right? [04:45] well, I'll try it :) [04:46] Don't forget to `bzr commit` the merge once you've reviewed its impact; [04:46] and `bzr revert --no-backup` if you screwed up and need to retry. [04:47] TiffanyAngel87: no, cherypicks don't, but they merge logic can still be [much] smart about what to do and how to apply the delta [especially normal forward cherry picks] [04:47] makes sense [04:48] AfC: I think that worked. And no conflicts thank god. thanks === vila_ is now known as vila [05:53] vila, hello? [05:53] thomi: hello? [05:53] Hello [05:53] hi all ! [06:03] thomi: hi, thanks for your work on the system config file, can we talk about it here or is it too late for you (what TZ are you in by the way ?) ? [06:03] I'm in New Zealand, so +1200 I think (or maybe +13? +11?) [06:03] by all means... [06:03] +12 [06:04] +13 in summer [06:04] * thumper leaves [06:05] Thank you thumper. [06:05] thomi: I haven't look in details so far, but roughly the missing parts are: [06:06] 1) I suspect the tests are not isolated yet and use the real /etc/bazaar.conf if it exists (instead of one specific to tests) [06:07] 2) the 'bzr config' command needs to taught about this new file (which means some heavy lifting) [06:07] 3) I'd strongly prefer if this new config file were implementing the planned features (path matching mainly) rather than duplicating the actual bazaar.conf [06:08] (3) could be simplified as a first step by duplicating branch.conf instead and forget about path matching as a first step [06:12] okay... [06:12] * thomi thinks [06:14] thomi: roughly, it means, the new file can be used for any options without any section [06:14] thomi: will that match your intended use ? [06:15] sure, I'm just hacking this for fun, we don't need this for sloecode... [06:16] ha, cool :) [06:16] so the plan regarding "bzr config" is to make the confi command use the new file, and then at some point in the future port the config command to use the new Stack API? [06:17] ...or do we port bzr config to the Stack-based API now? [06:18] that would be a different merge proposal, but yes, the plan is to move to the stack-based API asap [06:18] I haven't considered doing it so far because I wanted to migrate all the existing options first [06:19] but your proposal triggered a new way to think about the whole issue and may be we can use the system wide config to drive the introduction of the new features [06:20] ...but won't moving to the stack-based API give you access to the new system config file? I'm not sure what needs to be done for (2) in that case... [06:20] right [06:21] bzr config has a few needs that are not covered yet [06:22] from the top of my head: iterating all options returning (config-id, section, name, value) [06:27] okay, that makes sense. [06:28] just to make sure I'm not missing something, PathMatcher does not currently exist, right? [06:29] indeed [06:30] there are various candidates PathMatcher, URLMatcher, AbsolutePathMatcher, RelativePathMatcher [06:30] I don't think we need all of them ;) [06:31] but from a user point of view they address different needs [06:32] okay - I think I need to read the devnotes a couple more times :) I'll start by refining the unit tests and seeing how I can modify bzr config [06:33] Should be able to make some progress this weekend. [06:34] cool, I'll try to define a clearer roadmap for the missing bits and work on migrating more options myself [06:35] * vila hunts coffee [06:35] hah [06:36] On an unrelated note, is there an example someone can point me at of calling loggerhead to render *part* of an HTML page? I.e.- calling it from within another WSGI app? [06:36] It must be do-able because LP does it for merge proposals, but launchpad code makes my head hurt. [06:37] thomi: so lp is doing not in-process in a wsgi app, but from the client [06:37] proxied through the app server [06:37] it requests a diff url [06:38] ahh, that'd be why it looked odd. So is it something that's not currently easy to do in loggerhead? [06:39] from what i know of the structure i'd think it should be pretty possible [06:39] hm [06:39] depending on just what part it is that you want to get out [06:39] if it currently only serves one monolithic page for, say, annotate, and you want to get just part of it , you might need to refactor it [06:39] well, I'd like everything, but rendered within a sloecode page... [06:40] so, with sloecode navigation stuff inserted into the loggerhead page? [06:41] yeah, or rather loggerhead inserted into a sloecode page ;) [06:46] so how does LP do it for the diffs on merge proposals... I assume those diffs are created by loggerhead. [06:56] I don't think they are [06:57] oh, ok, cheers. [07:04] hi vila [07:04] do you want to chat? [07:05] yup, if my network agrees with that reasonable task ;) [07:14] jelmer: hi? [07:37] vila, so re http://doc.bazaar.canonical.com/devnotes/configuration.html compatibility [07:37] i agree we want to change section names [07:37] and delete some [07:38] right, more precisely we want to use sections to describe when the value applies, not what the key is [07:38] however, it seems pretty feasible to migrate while using the current files [07:38] i'd really rather not put users through a flag day [07:38] me neither [07:38] but we can support haveing both files defined [07:39] and even create one from the other [07:39] and even update the old one in parrallel (that one is probably overkill ?) [07:40] so istm the common case will be that people just simply have a bazaar.conf [07:40] with a default section, without bookmarks or aliases [07:41] trying to address all issues while keeping the same file gave me headaches and I never came to a satisfying solution either [07:41] and the simplest thing in that case is to just leave it alone [07:42] leave it alone and handles the new one or leave it alone and change its semantic ? [07:42] don't create a new file, just keep reading and writing the current location [07:43] support having this kind of section marker as a backward compatibility feature or something [07:44] :-/ [07:44] too hard? [07:44] my gut feeling is that it will make the code more complex with no guarantee that the end result will work correctly [07:45] roughly, we make assumptions about the file content and semantics that allow us to be lazy [07:46] as soon as you require looking at the file content to define the semantic, you lose the lazyness [07:46] what do you mean? [07:46] it matters less if we guarantee that we will read the file only once but we're not there yet [07:47] I mean: using [DEFAULT] as a backward compatibility marker means the file needs to be read first before deciding how we want to interpret it (not mentioning that it forbids using 'DEFAULT' as a valid path) [07:48] ok, so what i had in mind was [07:48] the per-user file is called bazaar.conf [07:48] we match sections by path in there [07:49] or, perhaps [path ...] [07:49] there's an api that will let the bookmarks and aliases plugins find other things [07:49] find values from other sections [07:50] right, but it's far easier to let the old file implements the old semantics and the new file provides the new ones [07:51] then people can decide when they want to switch [07:51] and we can deprecate bazaar.conf in 2.6 or 2.7 [07:51] i don't think that's a thing people want to make a decision about [07:52] using new features is a decision [07:52] deprecate bazaar.conf? [07:53] that's vincent's proposal [07:53] what do you think? [07:55] seems like a lot of people will need to change their config === vila_ is now known as vila [07:58] vila, so, i'm kind of -1 unless it's really necessary, and i'm not convinced yet that it is really necessary [07:58] please don't land it until i am convinced [07:58] i think there are other things we can do towards this that don't require that migration [07:59] like, getting rid of config-variable-specific apis, and updating callers to use stacks? [07:59] yes, that's what I refer to as 'migrating existing options' [08:01] ok [08:02] once we do that, we should be pretty much set to read them from a global file, the command line, or environment variables? [08:03] last time I looked at env variables the use cases seem to be that *multiple* env variables for *one* config option is the rule rather than the exception, but nothing blocking [08:03] command line will be ok [08:04] adding a global file (as in system-wide ?) without addressing the compatibility sounds like a waste of time [08:05] why? [08:05] ensuring single read/write of a given config file can also be done first (if only to free our minds about the related issues) [08:06] because it means we'll have to do the work twice [08:06] and the users too [08:07] uh [08:07] now, the migration to new files can probably be automated for the most common cases if not all [08:07] if you're suggesting adding a global file with a structure we later have to deprecate, that does seem like a waste, but i don't see why that would be needed [08:07] ha [08:09] I thought *you* were suggesting a system-wide file with the same semantics as bazaar.conf :) [08:10] i don't think we would need to handle the corner cases of bazaar.conf in the global one [08:11] right, that's why I suggested to make the system-wide conf file more like branch.conf: a single no-name section [08:11] to start with [08:12] but an obvious use case would be define aliases there... [08:12] cool [08:12] so then i think we'd have to update the alias code to look in both places [08:12] or, maybe add an api with a backwards-compatibility thing [08:13] or even better, let the config file define this kind of semantic so the backwards-compatibility tricks are easier to define and manage overall and clearer for users that could be pointed at the doc associated to the config file itself :) [08:14] but let's discuss about that later when things are clearer [08:17] just keep in mind that I'm fully aware that introducing new files and deprecating old ones is not easy/use-friendly, should be done with care and the costs/benefits balanced against keeping the same files [08:17] so step 0 is to send a roadmap and then step 1 is to migrate the existing callers [08:17] ok :) [08:17] poolie: in short: I damn well know the issues and I'm eager to convince you :) [08:17] ok :) [08:18] the other thing that would be really helpful now is your attention to http://package-import.ubuntu.com/status/ [08:19] config stuff is a good feature, and good for enabling other stuff, but not top of the list [08:20] jam: hello ! [08:21] morning vila [08:23] hi jam, welcome back [08:23] hi poolie [08:24] * vila biab [08:25] hi! [08:26] i've done multiple changes to a file which i'd like to put into separate commits. how can i do that? [08:27] remove one set of changes, commit, add the second changes back , commit [08:27] is there no way to edit the diff i'm committing? [08:27] probably not. [08:28] and i dont think there is a way to do that in any versioning system [08:28] you can select what files that have changes get commited but not certain changes in a file. [08:29] that sucks :( [08:29] commit more often i guess! [08:30] also, is there a way to make the mac version of bzr explorer have a dock icon? [08:30] its a one liner, but i have no idea where the program starts [08:32] cheater, use bzr shelve [08:32] or install bzr-interactive and i think it adds a commit -i [08:32] oh let me try that! [08:32] hi jam, welcome back :) [08:33] because its annoying to have the default python icon in the dock =/ [08:35] poolie: pong [08:35] hi jelmer [08:35] i think i was just saying hi [08:35] so what would i do? bzr shelve file, edit changes to just leave in the ones i need.. and then bzr ci.. and then how do i get my changes back? [08:36] bzr unshelve [08:36] ah [08:36] great - let me try that [08:39] wow bzr shelve is really great [08:39] thanks a lot for the tip! [08:40] AuroraBorealis: look, bzr is better than any other VCS :) [08:40] i didn't know it allowed you to choose what changes [08:40] yep! pretty cool! :) [08:44] btw, i wrote a lightweight text editor for use with bzr commits [08:45] i just do bzr ci, enter my message, then press Ctrl-D (or Ctrl-C) to abort). It doesn't do anything else and doesn't display any user interface, etc. [08:45] i find it better than nano and vim for this purpose, and you don't have to use -m (using -m means that you can't just press up and enter to commit new changes) [09:02] so, wanting to file a bug for making tags fetching optional for 2.4.0, I see we have 3 critical bugs ? [09:08] jelmer: bug #771184 sounds like the one I'm after [09:08] Launchpad bug 771184 in Bazaar "option to disable/enable fetching of all tags" [High,Confirmed] https://launchpad.net/bugs/771184 [09:09] vila: ah, yep [09:09] jelmer: do you know the fetch code enough to fix it ? [09:10] jam: or may be you do ? [09:12] mgz: Would really appreciate you looking over https://code.launchpad.net/~jml/testtools/unprintable-assertThat-804127/+merge/70530 [09:13] vila: enough to make fetching tags optional, or enough to fix the underlying bug? [09:13] anyway, I've marked #771184 as critical and targeted to 2.4.0 so we don't release without fixing it [09:13] jam: enough to make fetching tags optional [09:14] jam: so we can fix the underlying issue for 2.4.1 or trunk [09:15] jam: I don't understand the details but the underlying issue seemed to be tricky enough to require more time. I don't want to block the release for that [09:19] hi jelmer [09:19] vila: Yeah, I think I know the fetch code well enough, though I'm also trying to finish off my current WIP [09:19] hi Noldorin [09:20] hey [09:20] jelmer, haven't had any time to investigate that bzr-git issue yet really..... have you? [09:21] Noldorin, no [09:21] jelmer, might have some time tomorrow. was going to ask... [09:21] jelmer, you said to test "part" of the r47 commit. how do i do this? [09:24] Noldorin, creating a new revision with some of the changes present in r47 and seeing if that gives the same problem [09:24] then doing that until you can narrow down which combination of changes triggers the bug [09:27] jelmer, i would have to create a whole new branch, no? [09:29] jelmer, because just adding a new revision still leaves the old r47 and this gets pushed... [09:29] afaik [09:29] well, i tried indeed. [09:30] Noldorin: yeah, you would have to have these changes instead of your current r47 [09:31] jelmer, ok, thanks for confirming :-) [09:31] jelmer, bit mor time tomorrow, so we'll see! good night for now [09:40] Noldorin: g'night [09:40] jml: don't be shy, just call the branch f---ing-assertThat ;) [09:50] spiv: :) [09:51] * mwhudson wishes for hunk splitting in shelve [09:53] If shelve can't cope I usually revert and vimdiff [09:53] will anything bad happen if i edit a file that is shelved? [09:57] spiv: What I'd like to say about supporting unicode across Python 2 & 3 is unprintable. [09:58] mwhudson, you know you can set it up to allow you to edit hunks to achieve that? [09:59] james_w: no! [09:59] * james_w searches [09:59] bug 708716 [09:59] Launchpad bug 708716 in Bazaar "config change_editor is undiscoverable" [Low,Confirmed] https://launchpad.net/bugs/708716 [10:00] bug 781871 [10:00] Launchpad bug 781871 in Bazaar "change_editor for bzr shelve is still not documented enough" [Medium,Confirmed] https://launchpad.net/bugs/781871 [10:01] mwhudson, id:4D417FEE.3070409@ukr.net [10:02] oo [10:02] thanks [10:03] mwhudson, I think you edit the whole file to look like what you want after shelve completes, and it ignores any previous decisions you made in that file [10:03] I may be wrong though [10:11] is it possible to have one editor in bzr for commit messages, and another "general" editor? [10:57] Seriously people... [10:57] bzr co $URL; edit stuff; bzr ci --local because I'm on the train.. bzr push => "ERROR: No push location known or specified" [10:57] Would it be -that- much work to have this specialcase default to "Oh I'll just push up to the branch" since bzr info knows full well what it is [10:58] I don't think in $N years I have -ever- bzr checkout'ed anything that I ever wanted to push anywhere else other than back to its branch. [10:59] LeoNerd: please file a bug [10:59] * fullermd cues round 73 of bound-age. [10:59] Where do bugs go these days? [10:59] LeoNerd, http://bugs.launchpad.net/bzr/+filebug [11:00] Hrmmm... needs login.. [11:00] fullermd, I'm also not sure how useful bound branches are anymore these days [11:00] they seem to cause a lot of confusion for new users [11:00] I use them almost exclusively [11:01] They sound very useful, as that's what LeoNerd is wanting. [11:01] I want to work against my centralised repo server; the same workflow model as CVS or SVN [11:01] Me, I'm quite the opposite. I can't remember the last time I wanted a bound branch, but I use checkouts all the time. [11:01] To be honest, I mostly treat bzr as a "better svn", which has real branches/tags/renames/... [11:02] Ah, turns out to have been filed already. [11:03] https://bugs.launchpad.net/bzr/+bug/539996 [11:03] Ubuntu bug 539996 in Bazaar "bzr push should default to parent branch if that's writable" [Wishlist,Confirmed] [11:03] over a year ago [11:06] LeoNerd: "patches welcome" :) [11:06] Bah [11:06] I find that rarely to be the case. [11:06] I usually ask for a feature and then do nothing until someone official upstream says "please send a patch" [11:06] as in the past I've wasted lots of time and effort building patches that don't get accepted [11:07] LeoNerd, that's a different issue [11:07] Sure [11:07] LeoNerd, bug 539996 is a different issue from what you were describing I mean [11:07] Launchpad bug 539996 in Bazaar "bzr push should default to parent branch if that's writable" [Wishlist,Confirmed] https://launchpad.net/bugs/539996 [11:07] But to the outsider it's never clear if a feature is missing intentionally, or simply because nobody happens to have got around to it yet [11:07] That looks the same, no? [11:07] LeoNerd: That's also another issue :) [11:08] LeoNerd: at least I didn't say "patches accepted" :P [11:08] LeoNerd: you want "bzr push" to default to the *master* branch, which is different from the parent branch (which is the location a branch was "forked" from) [11:08] .. oh. [11:08] OK. I'll write another one [11:09] LeoNerd, I'd be interested in talking about patches and discussion around them [11:09] LeoNerd: obviously it can be a good thing to discuss what you're doing with the people that will need to approve before sinking too much effort into it, to make sure you're not doing something that will never be taken [11:10] spiv: Yes. I usually try [11:10] Quite often nobody replies ever [11:10] LeoNerd: "patches welcome" was just meant to be a shorthand for that. If you like, "feature suggestions and discussion about proposed patches also welcome." [11:10] Nono.. [11:10] Yeah, that's a tough problem. [11:10] those are -massively- different [11:10] LeoNerd, I've had similar issues in the past, but I think the process has improved significantly since [11:10] I am quite happy to talk, discuss, rant, foam-at-the-mouth about the feature(s) I happen to want or the bugs or whatever.. [11:11] If you invent a way to solve the finite amount of time developers have, well, we wouldn't need to ask for help with fixing bugs ;) [11:11] But I pointblank-refuse to write a single line of code unless someone semiofficial at least vaguely hints at "we will consider a fix if you supply one" [11:11] Sure [11:11] I agree that's wise [11:12] And if at first you get silence, make more noise (if you want, giving up is also fine!). Sometimes the right person is just really busy that week. [11:12] Sometimes.. [11:13] Depends on the project.. I have features/bugs/etc.. outstanding in some places for -years- unreplied [11:13] I think bzr is increasingly defaulting to "well none of the core devs care strongly either way, so if you want to write that patch go ahead and we'll accept it (if it meets the quality requirements etc)" [11:13] Oh yes, me too. [11:13] It depends very much on the project. [11:15] Whether your bugs/posts languish or get responses is a fairly good indicator for how pleasant it will be for you to work with that community, I think. [11:15] Heh... [11:15] Doesn't fill me with confidence then.. :/ [11:16] But then some aren't quite my problem. I have a bug open on FreeBSD that's basically in a state of "I really don't care, but I can't support your platform until this is fixed" [11:16] Things vary a lot there. [11:17] I submit port updates a lot, and they rarely take more than a couple days. And occasionally single-digit hours. [11:17] This isn't a simple ports issue [11:17] Meanwhile, I've got a 3-line manpage patch that's coming up on its 3rd birthday, without evidence of a glance. [11:17] This is a "er.. your kernel API is lacking a feature"... [11:17] I wrote a unit test and documentation and everything.. Just no -actual- implementation [11:17] But I handwaved in vague terms how it should be doable [11:19] Yes, but my point is that when the only things required is "patch ; cvs ci", the response time varies enormously (even before counting the random factors). [11:19] Getting somebody interested enough to write the code is an even larger can ;) [11:21] LeoNerd: that is a shame. Not that long ago I had a perfectly good (and complete) patch sit around for months and months in a project bug tracker, despite promises it would be looked at "soon" or "in a couple of weeks" and it was deeply frustrating. [11:22] Oh, I don't usually expect people to write code [11:22] I'm quite happy to write it _after_ I have the vague commitment that they might acutally consider it [11:23] I just dno't like that large upfront investment on such risky odds of return [11:23] Its' basic economics :) [11:23] Yes, very sensible! :) [11:24] I usually figure I might as well go for it. If it just gets taken, I look smart. If it languishes for years, eventually someone else will hit the problem, and I can point at the long-waiting solution and be all smug. [11:24] Kinda win-win :) [11:24] FWIW, the bzr team does try to be aware of these problems and fix them. We've spent a bunch of effort making sure the patch review queue never grows too long, and that bugs aren't left as "new" indefinitely, etc. [11:25] LeoNerd: hmm, and although it's not explicitly written down, I think it's part of the Patch Pilot role (which rotates weekly) to be someone you can talk to get a "yes we'd be interested in that patch / no we wouldn't" indication for something you might want to write. [11:26] LeoNerd: it might be a good idea to make that fact explicit and visible :) [11:26] fullermd: That only really works if the cost of writing the patch is small. I have a ~50line change to make to the core of the BSD kernel's kqueue handling. Kernel dev. requires a very large initial investment in setting up the dev. environment, virtual machnie, etc... [11:26] Again economically, it's a large outlay of capital on a risky venture [11:26] LeoNerd: I'll ping poolie about that, thanks for prompting the idea. [11:27] spiv: Hehe.. Oh; I'm not complaining about bzr specifically here; just open source in general. :) But if you guys can manage to be above-average, then great. [11:27] i'm still fairly annoyed at bzr not really working well when my internet access is faulty [11:28] i'll even get corruption [11:28] LeoNerd: yes, we'd like to be :) [11:28] or rather, the checkout goes into an unworkable state that's probably non-trivial to fix [12:57] is there a way to convert my checkout done with sftp:// to bzr+ssh:// ? [12:57] i really don't want to re-download half a gigabyte of stuff [12:59] cheater: Do you have a shared repository? [13:01] ? [13:01] vim [13:01] The checkout -data- is the same [13:01] The URL used to access it is transient [13:01] vim .bzr/branch/branch.conf :%g/sftp/bzr+ssh/ [13:01] er.. :%s/ [13:02] LeoNerd, is that really all? [13:03] i have noticed that, but i was wondering if there's any caveats [13:03] if it's this easy that's great [13:03] I've done it loads of times [13:03] Never broken anything for me [13:03] thank you [13:04] I guess a way to do it without editing the config directly is 'bzr pull --remember newurl' [13:05] Yah, but that only updates the pull location [13:05] If you're talking a _checkout_, you want 'switch'. [13:05] I often end up with three locations [13:05] parent, pull, push [13:05] .oO( because of that stupid bug ) [13:08] yeah it's a checkout [13:13] would you say that bzr+ssh is more durable/robust than sftp? [13:13] it certainly seems *faster* [13:16] cheater, it is faster, because the transport is not "dumb" [13:17] ok [13:17] cheater, It should generally be as reliable as bzr+ssh [13:18] sftp you mean? [13:18] yes [13:19] i'm having problems with the transport handling, e.g. if i ctrl-c out of a bzr update or commit i get runaway processes that keep spamming my console [13:19] cheater: the only time I've seen an advantage with sftp was on a *very* low-powered CPU machine on a fast local network. [13:19] i'll see in the future whether bzr+ssh does the same [13:19] cheater: can you describe/paste "spamming" ? [13:21] sure, i'll ctrl-c out when bzr is doing something, and then when i'm back in my shell i continuously get prompts for the password written out, and an information that the authentication failed (probably because the password doesn't get entered because there's nothing connected to the stdin) [13:21] i can't paste it right now but let me try to reproduce it [13:22] and is that with bzr+ssh or sftp [13:22] it's with sftp. i have just started using bzr+ssh. [13:22] I believe we tried to block ssh from receiving the ^C immediately, so that when connected, we can clean up more-cleanly [13:22] (we try to unlock, etc, and if SSH has been terminated, we can't do any of that.) [13:23] sometimes when i ^C i get bzr: interrupted [13:23] it seems to be handling it well then [13:24] but sometimes i get a python trace with KeyboardInterrupt [13:24] aha, no it doesn't [13:24] i have just triggered it [13:29] let me test a bit more [13:31]