[00:25] jelmer: http://bazaar.launchpad.net/~jelmer/openoffice/hosted/files [00:27] reasonably snappy in that view [00:28] yeah, i'm pleasantly surprised [00:28] mwhudson: nice [00:29] jelmer: the scanner is still choking on it if you try to look at the branch page :) [00:31] * spiv yawns... he slept in! === dereine is now known as dereine[OFF] [00:59] spiv: ping [01:00] spiv: I vant reviews ;) [01:00] lifeless: ok :) [01:01] lifeless: speaking of which... :-) [01:02] jelmer: right, push stuff? [01:02] lifeless: Yeah, InterBranch.pull() [01:04] I need to look at that in context with smart server pulls [01:04] I thought push would be sufficient, but it turns out it isn't [01:04] jelmer: how large is that openoffice import btw? [01:05] mwhudson: ~4.5 Gb IIRC [01:05] lifeless: k [01:06] jelmer: that's still pretty large! [01:07] lifeless: it now also looks like the InterBranch.pull / InterBranch.push code is necessary for svn nested trees support [01:08] jml: can you explain in a short sentence what "Is there a way to get lp-reviews to participate on the list the way BB does" means? [01:08] jelmer: ? [01:08] mwhudson: let me try :) [01:09] mwhudson: BB acts like a member of the list; it responds to things on the list ([MERGE] mails, and responses to [MERGE] mails with review commands in them), it sends mail to the list (when something is merged, or someone votes through the webui) [01:09] mwhudson: you never need to go to the webui [01:09] mwhudson: "Watch the mailing list for specially flagged messages; when these messages appear, create a merge proposal, send a message to that thread and monitor the discussion as if it were taking place on Launchpad" [01:10] lifeless: you never need to go to the webui for code reviews either [01:11] mwhudson: thats not the end goal; it would be a bit silly to have that as a goal. [01:11] the goal is to be inline with the list discussions [01:11] jml: so the problem with code review as it is is that you have to send things to special addresses? [01:11] lifeless: bzr nested tree support has a local dictionary of where external trees can be found, by file id [01:11] (merge@ for new proposal, mp+@ for comments) [01:11] jelmer: in Branch8, yes. [01:11] lifeless: that seems like a reasonable thing to do, given that their location can move and that you'd also want the historical location to move [01:11] mwhudson: I think the problem is that Launchpad will send the email out again [01:11] lifeless: in svn, that location is tied to the tree [01:12] mwhudson: and yes, the special address [01:12] lifeless: so whatever default infrastructure there is at the moment I'll need to override for push and pull [01:12] jml: mm, that too [01:12] mwhudson: I think abentley's last post on the thread nails the problems. [01:12] to the mast, like a flag. [01:12] mwhudson: bb *adds* to the discussions on the list; lp-reviews currently appears to want to own the discussion [01:13] participate vs being the forum [01:13] right [01:14] python's code reviews happen separately to discussion; I find it very hard to have any internal zeitgeist about whats in the pipeline there [01:16] lifeless: It sometimes feels like you guys want to use Code Review instead of Bundle Buggy, but want Code Review to be just like Bundle Buggy. [01:16] abentley: I love BB to bits; I think its soo close to Just Right that its not funny. [01:17] same here, except for the occasional downtime bb works really really well [01:18] abentley: I'd like to be using Code Review because it has all the admin stuff built in, uses the lp login rather than separate credentials, and is something other projects can trivially turn on [01:20] lifeless: OpenID authentication, even LP team awareness would be possible if I thought it was worth the effort. [01:21] of course; I think its better to keep improving Code Review though [01:22] also, it'd be pretty awesome if Code Review (which is general purpose) became as good for you as the custom-tailored tool BB [01:23] jml: indeed [01:23] by "pretty awesome", I meant "pleasantly surprising" [01:23] except that I don't see a reason to aim for anything lower than that [01:24] for instance, bb has nicer email syntax; why can't code review have as nice a syntax? [01:24] (quoting Aaron about it being nicer) [01:25] Code review makes me sad because it suggests I'll have to dive back into the mess of figuring out how to deal with LP's emails :| [01:25] I personally think the syntax should be: (review 'approve) [01:26] with options on (setq ok-to-merge-p (lambda () t)) [01:26] jml: :set jml_is_trolling=yes [01:26] jml: (lisp allowed be YHWH) ? [01:26] man, forgot the quote. [01:26] an, forgot the h [01:27] lifeless: nice syntax is vague and a little bit subjective. have you filed bugs about it? [01:27] and the m. fail cold fingers [01:27] jml: I've asked Aaron when I get told by lp that I got it wrong [01:28] jml: bug filing when one isn't sure its a bug feels like makework [01:29] lifeless: on this, our feelings differ. [01:30] I have, do and will file bugs whenever I think its a bug, but won't, and it will stay like that in the absence of some reason to think it should change [repeated 'have you filed bugs?' questions are not sufficient or necessary]. [01:30] bah missed the end of the phrase, [01:30] lifeless: ok [01:30] won't when I am not sure [01:31] so please, either tackle whatever issue you have head-on with me, or stop the somewhat snarky 'have you filed bugs' questions. [01:31] ok. [01:32] concretely, if you mean 'I think this is a bug, could you make sure there is one about this', thats fine - say that :) [01:32] lifeless: here's what I mean. [01:32] lifeless: I don't know what your difficulty with the launchpad mail review syntax was [01:33] lifeless: and I don't know how to find out what it is without asking you [01:33] lifeless: and until just now, I didn't know you had any issues at all. [01:34] lifeless: which makes it hard for me to participate (even silently) in discussions about making code review better for you. [01:35] thats all true [01:36] that said, every issue I've had I've brought with one or more developers of code review, at the time [01:36] when they say 'bug' I file a bug [01:36] which is great :) [01:37] but some things are open questions. it'd be good to have those discussed on some sort of asynchronous, stable medium. [01:37] whether the bug tracker (I'm very happy to say wontfix), or launchpad-users or something. [01:38] I'm not on lp-users; whats the SNR there like at the moment? [01:40] lifeless: there have been less than fifty threads this year. <5 are pure noise, the rest are divided about evenly between announcements, requests for help and suggestions [01:40] lifeless: launchpad-users is excellent [01:40] so low volume [01:40] i get the impression not all devs read it, but jml does [01:41] poolie: hi, wb! [01:41] https://launchpad.net/~launchpad-users -> LP down try again message :( [01:41] fwiw i rarely use the lp mail interface because signing is a slight hassle, but my miss rate when i do is no worse than BB [01:41] really? yikes. [01:41] lifeless: yeah me too [01:42] back now for me [01:42] morning [01:47] jml: two things [01:47] jml: I've forwarded you one discussion I had with Aaron to give you data. [01:47] lifeless: I saw that, thanks. [01:49] jml: but in general, I think its unreasonable to expect that every issue a user encounters of ones products *will* be in fora one is also in; one needs to deal with the discovery of issues that happened in the pasts by asking for that data, not by asking if the right thing was done [01:49] particularly when the right thing being done doesn't imply that you'd have had earlier access to that data. [01:52] lifeless: ok. [01:55] anyhoo; I'm on lp-users now; I won't guarantee to ask all questions there [01:55] lifeless: btw i saw last week that launchpad echelon is somewhere near the planning horizon for that team [01:55] by which i mean it may happen next year [01:55] if I have a review question and a faster/closer source is available, that source will be asked [01:55] that feature name will give the fudsters something to chew on :) [01:55] but, it means smarter two-way interaction with mailing lists, for instance telling bugs when they're being discussed [01:56] but when one isn't, I will ask lp users rather than private mail to a specific dev [01:56] jml: ^ [01:59] lifeless: sweet, thanks. [01:59] lifeless: so what's the bottom line as far as switching? [02:00] lifeless: the main thing for me is that if there's something left to do or to talk about further, we should get it written down somewhere. [02:00] poolie: Well, we can but try. I'm a little [lot] concerned that it partitions the list [02:01] the ui headaches are discussable [02:01] not having as clean an interface as bb is sad but not a deal breaker. [02:01] not getting the reviews into my bzr list folder is the biggest issue [02:02] is that just a matter of having suitable headers for filtering? [02:02] I don't know [02:02] anyhow, I think the next step should be what I asked for on the list [02:03] someone that knows code review's design, how its meant to work etc, should update our developer docs [02:03] to say how we should do things to work with code reviews [02:04] +1 [02:04] the exercise of doing that will beneficial in a few ways, and if it can't be done successfully that rather indicates that there is a showstopper :P [02:06] speaking of reviews [02:07] poolie: you resubmit:'d a patch of mine a while back, I disagreed, you went silent. [02:07] which one? [02:07] poolie: I've updated the patch and sent it for review again; this time I want bb:approve, even though I haven't changed that part fo the code. [02:08] http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1241072466.9565.45.camel%40lifeless-64%3E [02:08] concretely, -Dlock should only have a side effect while we fix up tests [02:08] once they are fixed the overload of using it to trigger error will go because the test suite will always error [02:09] so using a different variable really doesn't make sense to me, because you'll always with -Dlock -Dlock_check when testing during the transition fixup period [02:09] and -Dlock_check won't have any effect outside the test suite [02:11] poolie: jam has given tweak: but as you did 'resubmit' before I thought you'd appreciate the chance to see it again [02:12] isn't this what -E is supposed to be for? [02:12] * lifeless looks up -E [02:13] poolie: same thing [02:13] -Elock == -Dlock checked as the code does [02:14] what do you mean? [02:15] oh, its not quite the same [02:16] anyhow, the point is - I want a temporary thing for a transition period only [02:16] lifeless: aiui -E is for things that affect the running of the test suite [02:16] whereas debug_flags is isolated per test so that we can test -D [02:16] -Dlock already exists and is ideal for doing this [02:16] but won't it be masked off when each test runs? [02:16] no [02:16] anyhow, looking at that patch without rereading my original mail i have no objection [02:17] ok thanks [02:17] ^^ and with your explanation here [02:17] igc, re the option naming thread [02:17] i guess it's not a big deal but these threads seem kind of inefficient [02:17] (i'm not complaining about your posts at all i'm just thinking aloud) [02:18] there are some small things we want to fix, and they might be reflections of or connected to larger problems [02:18] and we need to fix the big things but i have this nagging feeling the conversation always goes on to that at the expense of making incremental changes [02:18] maybe it's ok and it's the only way we'll work up energy to do the big things [02:19] I think uncontentious small changes should just get done; and big things should be really carefully addressed - needs constraints, known lessons *before* putting solutions on the table [02:19] poolie: well even the big things usually end up being tackled a bit at a time [02:19] 'we're only as smart as the amount of time we spend before we come up with an answer' [02:19] poolie: the trick is making small changes along the right path [02:20] mm [02:20] i agree with both of you [02:20] i guess, i'd like the small things discussed more in terms of "this is going down the right/wrong path" rather than "oh look at this big problem over there" [02:21] poolie: UI threads have a history of spinning out of control - everyone and their dog has an opinion :-) [02:21] poolie: that suggests we should have the sprint asap to determine the path [02:21] right, and it's probably not worth squelching it [02:21] agree [02:21] and that's a general comment - not just for bzr [02:21] have to say i'm not feeling super keen on flying right at the moment [02:22] so, 1-should we do it before UDS; and 2-where? [02:22] I don't think we have time [02:23] 1 probably depends on whether we'll empty the brisbane core work queue [02:23] 2 weeks; several things to prep for allhands, network deltas needed, 1.15 to release, iter_changes to overhaul for commit [02:23] lifeless: I think you should do it at UDS and include me when you can [02:23] oops i forgot there'll be no igc [02:23] I think after UDS is likely best [02:24] before UDS, I agree with Robert - let's keep focus on 1.15 [02:24] bbc took the better part of a week for me to methodically aggregate our already learnt lessons and needs [02:24] its not a parallelisable task - more people doing it means more people have the aggregate state, but thats all [02:25] I for one are busy enough on nested tree reviews, tuning log dir performance and looking at branch-specific rules [02:25] heck, on nested trees I'm still deeply scared that we're basically going in the wrong direction [02:28] mmm, I should be more clear [02:29] on the planning sprint, I think we should do a bunch of analysis before hand [02:29] bbc is radically different to all the prior proposals [02:29] yet we'd talked about it at every sprint for the 3 or so years before [02:30] bbc is different because I took the time to really step back, clear head, and get to the root of the issues [02:31] someone needs to do the same thing for repository/branch management headache, inline-vs-checkouts and so on [02:32] on nested trees, what I mean is that having a lookaside datastructure and a composite tree really seems to drive complexity up to me, rather than having things that iterate choose to recurse when they want to [02:34] poolie: concretely, I think we should finish bbc; get commit fully fixed for it (someone needs to do iter_changes), get networking fully done (spiv and I are halfway through the delta representation, jelmer is reporting memory issues,...) [02:35] poolie: we should estimate when we'll get these things done (soon!) and plan a sprint in brisbane a few weeks after that [02:35] a few weeks to allow time to sit and think *before* we get together. [02:38] I think it's really import we keep focus on nailing networking & making bbc production strength right now [02:39] spiv: does 'bzr serve' use a thread-per-request model? [02:40] mwhudson: yes [02:44] spiv: how do you think it would scale to 100 concurrent connections? :) [02:44] mwhudson: depends on what the connnections do :) [02:45] mwhudson: (I don't really have any basis to make a good guess about it) [02:46] spiv: well, i'd be pretty confident that if it forked, it wouldn't do very well at 100 connections [02:46] spiv: i guess if it only did vfs stuff, it wouldn't use much ram? [02:46] Right. [02:47] you don't need to alter bzr at all to just do vfs stuff :P [02:47] (there may be bugs with transferring large files, but if so we can fix those...) [02:48] lifeless: i'm not sure what you're saying [02:48] mwhudson: I mean that the methods available are just in a dict [02:48] a plugin can strip them back to a 'I want these only' set [02:49] yes, spiv already said as much in an email [02:49] cool [02:54] jelmer: is that packed? [02:55] lifeless: the memory usage thing? [02:56] lifeless: It was 4 packs, all around 1Gb [02:56] thumper: ^ it will shrink :P [02:56] jelmer: I suspect it will shrink massively if you pack it [02:56] jelmer: I was asking for disk space usage, not about the memory bug [02:56] ah [02:56] the memory thing you need to debug [02:57] lifeless: do I need to buy more memory first before I pack ? :-) [02:57] no [03:04] poolie: you've gone quiest [03:04] silence indicated assent [03:04] cool [03:04] also, sneezing my head off :) [03:04] (thunk) [03:04] :( [03:05] but seriously that did sound like a good plan [03:06] spiv: actually, jam has reviewed stuff; I just didn't see it because he didn't copy me/used the web ui [03:31] * igc lunch [03:34] lifeless: i think we should create a ~bazaar-reviews team, enable its mailing list feature, and subscribe it to reviews [03:35] that should mean there's a single archive for all reviews, people can subscribe to just reviews if they wish, and they can read it through gmane etc [03:37] poolie: we already have a lsit of all devs [03:37] poolie: why create a new list? [03:38] poolie: nevertheless; I reiterate - updating our docs should be the next step. [03:39] we don't have to land the updated docs until we're happy, but we should be updating them before changing the workflow [03:39] because they are meant to be our reference manual [03:39] lifeless: i'd create a new list just because avoiding mixing paint in lists seems to be a good guideline in launchpad [03:40] you can always add ~bzr to that new team or vice versa [03:40] cf problems with bialix not wanting the ppa spam sent to ~bzr [03:40] I actually mean bazaar@lists.canonical.com :) [03:47] if that works properly that's fine [03:47] so, actually i wonder about migrating our list there too [03:47] that might be nice [03:47] mostly in the hope of getting less spam to deal with manually [03:48] I think the spam will be identical [03:48] it seems like i'm the only person who moderates the list, it gets hundreds of spams per week, and it's either not possible or not a priority for IS to make the filtering better [03:48] what I want for reviews is for us to 1) update docs 2) search for solutions found doing that 3) trial, 4) mov [03:48] um [03:48] e [03:48] it looks like a broken filter to me [03:49] i don't get nearly so many unfiltered spam in my own mail [03:49] if the docs end up saying 'join team A and join team B' then I think something is broken [03:49] anyhow i agree with that plan, except that the stages can overlap [03:49] lp makes it hard to undo mistakes [03:50] but sure, I'm not against some overlap; I am against us forgetting to do one of these because we rush ahead; and I definitely want a clear separation between 'investigate how it works' and 'move' [03:56] I think broadly I'm being conservative because missed reviews are a pain, and we often have a backlog *anyway* so its worth a small number of people doing the analysis of a move before many people are affected [03:56] see for instances python's dvcs pep for a similar situation [03:59] ok [03:59] lifeless: btw my previous review for -Dlock did also mention updating the flag documentation [03:59] if this is only transitional it may not be a big deal [04:00] poolie: right [04:00] its a bandaid until we can always be asserting [04:00] poolie: have I mentioned my little aws gui ? [04:00] no [04:01] bzr branch lp:~lifeless/txaws/client; cd client; bin/aws-status [04:13] Well, I gotta say, I'm considerably happier with my Bazaar experience since this morning when I figured out that the bzr-eclipse plugin apparently chokes on spaces in paths. [04:15] heh :( [04:15] Now it's just a question of exactly how I'm going to use it. [04:28] hi all, anybody using bzr on windows? I need some help, please. [04:29] helebek: ask your question :) [04:29] helebek: ask, and an answer you shall receive. [04:29] poolie: let me know what you thnk of the aws gui [04:31] I installed the windows binaries from the bazaar website successfully. Everything I do local works fine, when I try sftp I get an error from a python script. If I use bzr+ssh I get a connection closed error. Any ideas? [04:31] thank you, btw [04:33] helebek: can you connect to the host with putty? [04:33] yes I can connect with putty and plink [04:34] With sftp://python script giving the error is transport.py (line 213). It says "AttributeError: 'str' object has no attribute 'get' " [04:34] oh, yikes. might be a known issue. lifeless? [04:36] With bzr+ssh it asks for the password and then says authentication is successful. Then buff "bzr: ERROR: Connection closed: please check connectivity and permissions" [04:37] Kilroo: that kind of sucks, can you file a bug please? javierder is working on it quite actively [04:38] I think there's already a bug on it, actually. [04:38] lifeless/others, rfc, i'm cleaning up the ui stuff and am thinking of merging all of bzrlib/ui/*py into just one ui.py [04:38] it may marginally improve load time [04:38] and some of the files are getting small [04:38] any conceptual objections, and also [04:38] No, wait. That might have been for spaces in a url you're trying to pull from. [04:39] I'll check, and either file or comment as appropriate [04:39] poolie: conceptual objection: its mixing paint :P. [04:39] i vaguely recall implementation problems with python (pyc files?) when a directory module turns into a file [04:39] poolie: the other transform is a problem [04:39] foo.pyc is found before foo/__init__.pyc [04:40] but as long as you don't give the path any spaces to turn into %20's, you don't run into situations where bzr-eclipse can't find your working tree because there's no such place as My%20Documents. [04:40] so you want the base class separate from the text version? [04:40] Kilroo: the rule is this (modulo bugs): if it's a URL, it should be escaped as %20; if it's a non-url filename it should not have those escapes [04:41] I think it is cleaner, particularly when we expect dramatically different implementations aorund [04:41] e.g. gtk [04:41] Kilroo: please be sure to file a bug on bzr-eclipse [04:42] poolie: " [04:42] poolie: " [04:42] Reporting suggestions through the bug tracker is fine, though if they're [04:42] likely to be controversial or require extensive discussion it's better [04:42] to go to the list. (This one doesn't.)" [04:42] poolie: ^ thats why I want to keepreviews on the list :) [04:47] lifeless: so the subdirectory is a nonissue you think? [04:47] why? [04:48] well, actually [04:48] there are a few related issues [04:49] aiui the objections to discussing features in the bug tracker are: new designs may not break down into clear separate actionable bugs at first [04:49] some people may want to be involved but not subscribed to all bugs [04:49] bugs are just linear unthreaded and not so good for long conversations [04:50] and it's good for a bug to just contain a summary of what needs to be done not the full discussion [04:50] personally i mostly agree with most of them [04:51] the third doesn't apply to code reviews which are threaded (though they may be inferior to mail in other ways) [04:51] regarding the first and last, i would agree that general discussion should be separate from discussing a particular patch [04:51] but that's true on the list as well [04:52] the existence of code isn't a reliable separator for those things [04:52] how often do we have a thread turn into a patch, or vice verca [04:54] I find that question moderately intriguing. [04:54] bad quotes from other channels: "It was once said a Black man would be President when pigs fly.Indeed 100 days into Obama's presidency,swine flu." [04:57] back shortly, lunchy style break time [06:54] poolie: did you give aws-status a spin? [06:59] ew [07:00] lifeless: not yet, are you really keen that i do? [07:00] i guess so or you wouldn't be asking... :) [07:03] well, I know that activation energy is the large thing usually [07:04] my theory is if I nag you past that, you'll give it a spin and it will be there thereafter if you want to play more :) [07:09] it may work better if i'm already in aws-mode [07:09] at the moment i've been in email mode striving for finishing-ui-mode [07:09] :) [07:09] now interrupted by shops-mode [07:09] and, i may not return this afternoon actually [07:09] so have a good weekend if i don't see you [07:09] you too [07:09] bug me about it again [07:09] you can be sure of that :) [07:10] did you fly in this morning? [07:13] if any of have a spare moment, could you please take a look at https://bugs.edge.launchpad.net/launchpad-code/+bug/310347 [07:13] Launchpad bug 310347 in launchpad-code "Temporary "Could not install revisions" error" [High,Triaged] [07:18] jml: added a spare comment ;) [07:18] spiv: thanks :) [07:20] hmm, evo quit by itsself. fun [07:41] wish me luck, that batch of hpss patches is wending its way up to pqm now [07:48] lifeless: good luck. [07:52] spiv: I just sent a patch to the mailing list that you might approve of. [08:07] jml: bazaar ? [08:08] lifeless: yeah. [08:15] lifeless, spiv: can one of you two please land that for me? [08:15] I wonder if I should try to get pqm privs for bzr. === dereine[OFF] is now known as dereine [08:21] jml: I can do that now, sure. [08:21] spiv: thanks. [08:21] jml: I only held off because I wondered if perhaps you already had privs :) [08:22] spiv: I'm pretty sure I don't. (Is there a way to find out, other than submitting?) [08:22] jml: ask lifeless (or equiv. pqm admin) [08:28] jml: ask spm [08:28] night all [08:28] ok. thanks. [08:28] lifeless: g'night. [08:28] lifeless: too late I'm not here.... oops. [08:28] damn. shouldn't have responded. [08:29] jml: actually - that is something best sent via rt. if only so that we have the audit trail if you ken. [08:30] spm: asking *about* != asking for [08:30] spm: yeah, although right now I'm only interested in finding out whether I have permissions. [08:31] spm: and I'd rather just submit a branch than file an RT to figure that one out :) [08:32] jml: :-) and no, you dont have access [08:32] spm: ta [08:49] and it landed, woo [08:52] jml: pqm got a conflict, presumably with what lifeless just landed, resolving and firing again. [08:52] spiv: thanks. [08:53] spm: presumably :P [08:53] bah [08:53] spiv: ^ [08:53] spiv: also, way less roundtrips. We're under 9! [08:56] lifeless: Nice. Very nice! [09:10] not stacked sadly [09:10] anyhoo next week I want us to pair [09:11] and figure out sketches for getting the rest down [09:12] * igc dinner === dereine is now known as dereine[OFF] === dereine[OFF] is now known as dereine [11:57] is there a way to rename a branch or just push revision with new name? [11:58] gnomefreak: Just...rename the directory with your standard "mv" or whatever. [11:59] Peng_: that would consit of sshing into launchpad right? if so how [12:00] gnomefreak: Oooh, Launchpad. Can't you do it from the web UI? [12:00] checking [12:01] under change details is what i want i think [12:02] Peng_: thanks it worked [12:03] :) === dereine is now known as dereine[OFF] === dereine[OFF] is now known as dereine [12:27] Hmmm. 'bzr revert' doesn't seem to back changes up if the file is involved in a conflict caused during a pull. [12:28] Is that because it tries to avoid backing up changes during merges, and assumes that a conflict could only result from a merge onto a clean tree? === dereine is now known as dereine[OFF] === dereine[OFF] is now known as dereine [12:59] Hm. bzr-git is now at 10 minutes CPU time and 2GiB RAM useage, but it looks like it's a-workin. [13:00] * RAOF thanks jml for the extra GB of ram. [13:04] On the plus side, the ram usage is steadily decreasing. === dereine is now known as dereine[OFF] [14:11] hi, is there a PPA for bzr-gtk? [14:13] wgrant: we record the hash of files output during merge [14:13] bac: https://edge.launchpad.net/ubuntu/+ppas?name_filter=bzr-gtk suggests that there are several official-looking ones. [14:13] wgrant: so we can revert cleanly without backups then [14:13] lifeless: Right, I've since looked through that code thoroughly. [14:13] thank wgrant [14:13] lifeless: Bug #370334 [14:13] Launchpad bug 370334 in bzr "Reverting a file conflicted from a pull loses changes" [Undecided,New] https://launchpad.net/bugs/370334 [14:14] lifeless: But you can't revert to the files immediately before the merge. [14:14] lifeless: Because they were uncommitted changes. [14:16] wgrant: mark it confirmed high :) [14:17] wgrant: doesn't look like any of those support bzr 1.14. [14:17] lifeless: Thanks! [14:17] lifeless: Er, but I have no bzr Importance privileges. [14:18] wgrant: join the team :P [14:18] or remind me tomorrow; its late here [14:18]