| mwhudson | jelmer: http://bazaar.launchpad.net/~jelmer/openoffice/hosted/files | 00:25 |
|---|---|---|
| lifeless | reasonably snappy in that view | 00:27 |
| mwhudson | yeah, i'm pleasantly surprised | 00:28 |
| jelmer | mwhudson: nice | 00:28 |
| mwhudson | jelmer: the scanner is still choking on it if you try to look at the branch page :) | 00:29 |
| * spiv yawns... he slept in! | 00:31 | |
| === dereine is now known as dereine[OFF] | ||
| lifeless | spiv: ping | 00:59 |
| lifeless | spiv: I vant reviews ;) | 01:00 |
| spiv | lifeless: ok :) | 01:00 |
| jelmer | lifeless: speaking of which... :-) | 01:01 |
| lifeless | jelmer: right, push stuff? | 01:02 |
| jelmer | lifeless: Yeah, InterBranch.pull() | 01:02 |
| lifeless | I need to look at that in context with smart server pulls | 01:04 |
| lifeless | I thought push would be sufficient, but it turns out it isn't | 01:04 |
| mwhudson | jelmer: how large is that openoffice import btw? | 01:04 |
| jelmer | mwhudson: ~4.5 Gb IIRC | 01:05 |
| jelmer | lifeless: k | 01:05 |
| mwhudson | jelmer: that's still pretty large! | 01:06 |
| jelmer | lifeless: it now also looks like the InterBranch.pull / InterBranch.push code is necessary for svn nested trees support | 01:07 |
| mwhudson | 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 |
| lifeless | jelmer: ? | 01:08 |
| jml | mwhudson: let me try :) | 01:08 |
| lifeless | 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 |
| lifeless | mwhudson: you never need to go to the webui | 01:09 |
| jml | 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:09 |
| mwhudson | lifeless: you never need to go to the webui for code reviews either | 01:10 |
| lifeless | mwhudson: thats not the end goal; it would be a bit silly to have that as a goal. | 01:11 |
| lifeless | the goal is to be inline with the list discussions | 01:11 |
| mwhudson | jml: so the problem with code review as it is is that you have to send things to special addresses? | 01:11 |
| jelmer | lifeless: bzr nested tree support has a local dictionary of where external trees can be found, by file id | 01:11 |
| mwhudson | (merge@ for new proposal, mp+<id>@ for comments) | 01:11 |
| lifeless | jelmer: in Branch8, yes. | 01:11 |
| jelmer | 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 |
| jml | mwhudson: I think the problem is that Launchpad will send the email out again | 01:11 |
| jelmer | lifeless: in svn, that location is tied to the tree | 01:11 |
| jml | mwhudson: and yes, the special address | 01:12 |
| jelmer | lifeless: so whatever default infrastructure there is at the moment I'll need to override for push and pull | 01:12 |
| mwhudson | jml: mm, that too | 01:12 |
| jml | mwhudson: I think abentley's last post on the thread nails the problems. | 01:12 |
| jml | to the mast, like a flag. | 01:12 |
| lifeless | mwhudson: bb *adds* to the discussions on the list; lp-reviews currently appears to want to own the discussion | 01:12 |
| lifeless | participate vs being the forum | 01:13 |
| mwhudson | right | 01:13 |
| lifeless | 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:14 |
| abentley | 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 |
| lifeless | abentley: I love BB to bits; I think its soo close to Just Right that its not funny. | 01:16 |
| jelmer | same here, except for the occasional downtime bb works really really well | 01:17 |
| lifeless | 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:18 |
| abentley | lifeless: OpenID authentication, even LP team awareness would be possible if I thought it was worth the effort. | 01:20 |
| lifeless | of course; I think its better to keep improving Code Review though | 01:21 |
| jml | 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:22 |
| lifeless | jml: indeed | 01:23 |
| jml | by "pretty awesome", I meant "pleasantly surprising" | 01:23 |
| jml | except that I don't see a reason to aim for anything lower than that | 01:23 |
| lifeless | for instance, bb has nicer email syntax; why can't code review have as nice a syntax? | 01:24 |
| lifeless | (quoting Aaron about it being nicer) | 01:24 |
| fullermd | 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 |
| jml | I personally think the syntax should be: (review 'approve) | 01:25 |
| jml | with options on (setq ok-to-merge-p (lambda () t)) | 01:26 |
| spiv | jml: :set jml_is_trolling=yes | 01:26 |
| lifeless | jml: (lisp allowed be YHWH) ? | 01:26 |
| jml | man, forgot the quote. | 01:26 |
| lifeless | an, forgot the h | 01:26 |
| jml | lifeless: nice syntax is vague and a little bit subjective. have you filed bugs about it? | 01:27 |
| lifeless | and the m. fail cold fingers | 01:27 |
| lifeless | jml: I've asked Aaron when I get told by lp that I got it wrong | 01:27 |
| lifeless | jml: bug filing when one isn't sure its a bug feels like makework | 01:28 |
| jml | lifeless: on this, our feelings differ. | 01:29 |
| lifeless | 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 |
| lifeless | bah missed the end of the phrase, | 01:30 |
| jml | lifeless: ok | 01:30 |
| lifeless | won't when I am not sure | 01:30 |
| lifeless | so please, either tackle whatever issue you have head-on with me, or stop the somewhat snarky 'have you filed bugs' questions. | 01:31 |
| jml | ok. | 01:31 |
| lifeless | 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 |
| jml | lifeless: here's what I mean. | 01:32 |
| jml | lifeless: I don't know what your difficulty with the launchpad mail review syntax was | 01:32 |
| jml | lifeless: and I don't know how to find out what it is without asking you | 01:33 |
| jml | lifeless: and until just now, I didn't know you had any issues at all. | 01:33 |
| jml | lifeless: which makes it hard for me to participate (even silently) in discussions about making code review better for you. | 01:34 |
| lifeless | thats all true | 01:35 |
| lifeless | that said, every issue I've had I've brought with one or more developers of code review, at the time | 01:36 |
| lifeless | when they say 'bug' I file a bug | 01:36 |
| jml | which is great :) | 01:36 |
| jml | but some things are open questions. it'd be good to have those discussed on some sort of asynchronous, stable medium. | 01:37 |
| jml | whether the bug tracker (I'm very happy to say wontfix), or launchpad-users or something. | 01:37 |
| lifeless | I'm not on lp-users; whats the SNR there like at the moment? | 01:38 |
| jml | 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 |
| poolie | lifeless: launchpad-users is excellent | 01:40 |
| poolie | so low volume | 01:40 |
| poolie | i get the impression not all devs read it, but jml does | 01:40 |
| jml | poolie: hi, wb! | 01:41 |
| lifeless | https://launchpad.net/~launchpad-users -> LP down try again message :( | 01:41 |
| poolie | 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 |
| jml | really? yikes. | 01:41 |
| poolie | lifeless: yeah me too | 01:41 |
| poolie | back now for me | 01:42 |
| igc | morning | 01:42 |
| lifeless | jml: two things | 01:47 |
| lifeless | jml: I've forwarded you one discussion I had with Aaron to give you data. | 01:47 |
| jml | lifeless: I saw that, thanks. | 01:47 |
| lifeless | 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 |
| lifeless | particularly when the right thing being done doesn't imply that you'd have had earlier access to that data. | 01:49 |
| jml | lifeless: ok. | 01:52 |
| lifeless | anyhoo; I'm on lp-users now; I won't guarantee to ask all questions there | 01:55 |
| poolie | lifeless: btw i saw last week that launchpad echelon is somewhere near the planning horizon for that team | 01:55 |
| poolie | by which i mean it may happen next year | 01:55 |
| lifeless | if I have a review question and a faster/closer source is available, that source will be asked | 01:55 |
| poolie | that feature name will give the fudsters something to chew on :) | 01:55 |
| poolie | but, it means smarter two-way interaction with mailing lists, for instance telling bugs when they're being discussed | 01:55 |
| lifeless | but when one isn't, I will ask lp users rather than private mail to a specific dev | 01:56 |
| lifeless | jml: ^ | 01:56 |
| jml | lifeless: sweet, thanks. | 01:59 |
| poolie | lifeless: so what's the bottom line as far as switching? | 01:59 |
| jml | 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 |
| lifeless | poolie: Well, we can but try. I'm a little [lot] concerned that it partitions the list | 02:00 |
| lifeless | the ui headaches are discussable | 02:01 |
| lifeless | not having as clean an interface as bb is sad but not a deal breaker. | 02:01 |
| lifeless | not getting the reviews into my bzr list folder is the biggest issue | 02:01 |
| poolie | is that just a matter of having suitable headers for filtering? | 02:02 |
| lifeless | I don't know | 02:02 |
| lifeless | anyhow, I think the next step should be what I asked for on the list | 02:02 |
| lifeless | someone that knows code review's design, how its meant to work etc, should update our developer docs | 02:03 |
| lifeless | to say how we should do things to work with code reviews | 02:03 |
| jml | +1 | 02:04 |
| lifeless | 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:04 |
| lifeless | speaking of reviews | 02:06 |
| lifeless | poolie: you resubmit:'d a patch of mine a while back, I disagreed, you went silent. | 02:07 |
| poolie | which one? | 02:07 |
| lifeless | 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:07 |
| lifeless | http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1241072466.9565.45.camel%40lifeless-64%3E | 02:08 |
| lifeless | concretely, -Dlock should only have a side effect while we fix up tests | 02:08 |
| lifeless | once they are fixed the overload of using it to trigger error will go because the test suite will always error | 02:08 |
| lifeless | 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 |
| lifeless | and -Dlock_check won't have any effect outside the test suite | 02:09 |
| lifeless | poolie: jam has given tweak: but as you did 'resubmit' before I thought you'd appreciate the chance to see it again | 02:11 |
| poolie | isn't this what -E is supposed to be for? | 02:12 |
| * lifeless looks up -E | 02:12 | |
| lifeless | poolie: same thing | 02:13 |
| lifeless | -Elock == -Dlock checked as the code does | 02:13 |
| poolie | what do you mean? | 02:14 |
| lifeless | oh, its not quite the same | 02:15 |
| lifeless | anyhow, the point is - I want a temporary thing for a transition period only | 02:16 |
| poolie | lifeless: aiui -E is for things that affect the running of the test suite | 02:16 |
| poolie | whereas debug_flags is isolated per test so that we can test -D | 02:16 |
| lifeless | -Dlock already exists and is ideal for doing this | 02:16 |
| poolie | but won't it be masked off when each test runs? | 02:16 |
| lifeless | no | 02:16 |
| poolie | anyhow, looking at that patch without rereading my original mail i have no objection | 02:16 |
| lifeless | ok thanks | 02:17 |
| poolie | ^^ and with your explanation here | 02:17 |
| poolie | igc, re the option naming thread | 02:17 |
| poolie | i guess it's not a big deal but these threads seem kind of inefficient | 02:17 |
| poolie | (i'm not complaining about your posts at all i'm just thinking aloud) | 02:17 |
| poolie | there are some small things we want to fix, and they might be reflections of or connected to larger problems | 02:18 |
| poolie | 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 |
| poolie | maybe it's ok and it's the only way we'll work up energy to do the big things | 02:18 |
| lifeless | 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 |
| igc | poolie: well even the big things usually end up being tackled a bit at a time | 02:19 |
| lifeless | 'we're only as smart as the amount of time we spend before we come up with an answer' | 02:19 |
| igc | poolie: the trick is making small changes along the right path | 02:19 |
| poolie | mm | 02:20 |
| poolie | i agree with both of you | 02:20 |
| poolie | 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:20 |
| igc | poolie: UI threads have a history of spinning out of control - everyone and their dog has an opinion :-) | 02:21 |
| lifeless | poolie: that suggests we should have the sprint asap to determine the path | 02:21 |
| poolie | right, and it's probably not worth squelching it | 02:21 |
| poolie | agree | 02:21 |
| igc | and that's a general comment - not just for bzr | 02:21 |
| poolie | have to say i'm not feeling super keen on flying right at the moment | 02:21 |
| poolie | so, 1-should we do it before UDS; and 2-where? | 02:22 |
| lifeless | I don't think we have time | 02:22 |
| poolie | 1 probably depends on whether we'll empty the brisbane core work queue | 02:23 |
| lifeless | 2 weeks; several things to prep for allhands, network deltas needed, 1.15 to release, iter_changes to overhaul for commit | 02:23 |
| igc | lifeless: I think you should do it at UDS and include me when you can | 02:23 |
| poolie | oops i forgot there'll be no igc | 02:23 |
| lifeless | I think after UDS is likely best | 02:23 |
| igc | before UDS, I agree with Robert - let's keep focus on 1.15 | 02:24 |
| lifeless | bbc took the better part of a week for me to methodically aggregate our already learnt lessons and needs | 02:24 |
| lifeless | its not a parallelisable task - more people doing it means more people have the aggregate state, but thats all | 02:24 |
| igc | I for one are busy enough on nested tree reviews, tuning log dir performance and looking at branch-specific rules | 02:25 |
| lifeless | heck, on nested trees I'm still deeply scared that we're basically going in the wrong direction | 02:25 |
| lifeless | mmm, I should be more clear | 02:28 |
| lifeless | on the planning sprint, I think we should do a bunch of analysis before hand | 02:29 |
| lifeless | bbc is radically different to all the prior proposals | 02:29 |
| lifeless | yet we'd talked about it at every sprint for the 3 or so years before | 02:29 |
| lifeless | bbc is different because I took the time to really step back, clear head, and get to the root of the issues | 02:30 |
| lifeless | someone needs to do the same thing for repository/branch management headache, inline-vs-checkouts and so on | 02:31 |
| lifeless | 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:32 |
| lifeless | 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:34 |
| lifeless | 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 |
| lifeless | a few weeks to allow time to sit and think *before* we get together. | 02:35 |
| igc | I think it's really import we keep focus on nailing networking & making bbc production strength right now | 02:38 |
| mwhudson | spiv: does 'bzr serve' use a thread-per-request model? | 02:39 |
| spiv | mwhudson: yes | 02:40 |
| mwhudson | spiv: how do you think it would scale to 100 concurrent connections? :) | 02:44 |
| spiv | mwhudson: depends on what the connnections do :) | 02:44 |
| spiv | mwhudson: (I don't really have any basis to make a good guess about it) | 02:45 |
| mwhudson | spiv: well, i'd be pretty confident that if it forked, it wouldn't do very well at 100 connections | 02:46 |
| mwhudson | spiv: i guess if it only did vfs stuff, it wouldn't use much ram? | 02:46 |
| spiv | Right. | 02:46 |
| lifeless | you don't need to alter bzr at all to just do vfs stuff :P | 02:47 |
| spiv | (there may be bugs with transferring large files, but if so we can fix those...) | 02:47 |
| mwhudson | lifeless: i'm not sure what you're saying | 02:48 |
| lifeless | mwhudson: I mean that the methods available are just in a dict | 02:48 |
| lifeless | a plugin can strip them back to a 'I want these only' set | 02:48 |
| mwhudson | yes, spiv already said as much in an email | 02:49 |
| lifeless | cool | 02:49 |
| lifeless | jelmer: is that packed? | 02:54 |
| jelmer | lifeless: the memory usage thing? | 02:55 |
| jelmer | lifeless: It was 4 packs, all around 1Gb | 02:56 |
| lifeless | thumper: ^ it will shrink :P | 02:56 |
| lifeless | jelmer: I suspect it will shrink massively if you pack it | 02:56 |
| lifeless | jelmer: I was asking for disk space usage, not about the memory bug | 02:56 |
| jelmer | ah | 02:56 |
| lifeless | the memory thing you need to debug | 02:56 |
| jelmer | lifeless: do I need to buy more memory first before I pack ? :-) | 02:57 |
| lifeless | no | 02:57 |
| lifeless | poolie: you've gone quiest | 03:04 |
| poolie | silence indicated assent | 03:04 |
| lifeless | cool | 03:04 |
| poolie | also, sneezing my head off :) | 03:04 |
| poolie | (thunk) | 03:04 |
| lifeless | :( | 03:04 |
| poolie | but seriously that did sound like a good plan | 03:05 |
| lifeless | spiv: actually, jam has reviewed stuff; I just didn't see it because he didn't copy me/used the web ui | 03:06 |
| * igc lunch | 03:31 | |
| poolie | lifeless: i think we should create a ~bazaar-reviews team, enable its mailing list feature, and subscribe it to reviews | 03:34 |
| poolie | 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:35 |
| lifeless | poolie: we already have a lsit of all devs | 03:37 |
| lifeless | poolie: why create a new list? | 03:37 |
| lifeless | poolie: nevertheless; I reiterate - updating our docs should be the next step. | 03:38 |
| lifeless | 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 |
| lifeless | because they are meant to be our reference manual | 03:39 |
| poolie | lifeless: i'd create a new list just because avoiding mixing paint in lists seems to be a good guideline in launchpad | 03:39 |
| poolie | you can always add ~bzr to that new team or vice versa | 03:40 |
| poolie | cf problems with bialix not wanting the ppa spam sent to ~bzr | 03:40 |
| lifeless | I actually mean bazaar@lists.canonical.com :) | 03:40 |
| poolie | if that works properly that's fine | 03:47 |
| poolie | so, actually i wonder about migrating our list there too | 03:47 |
| lifeless | that might be nice | 03:47 |
| poolie | mostly in the hope of getting less spam to deal with manually | 03:47 |
| lifeless | I think the spam will be identical | 03:48 |
| poolie | 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 |
| lifeless | 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 |
| poolie | um | 03:48 |
| lifeless | e | 03:48 |
| poolie | it looks like a broken filter to me | 03:48 |
| poolie | i don't get nearly so many unfiltered spam in my own mail | 03:49 |
| lifeless | if the docs end up saying 'join team A and join team B' then I think something is broken | 03:49 |
| poolie | anyhow i agree with that plan, except that the stages can overlap | 03:49 |
| lifeless | lp makes it hard to undo mistakes | 03:49 |
| lifeless | 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:50 |
| lifeless | 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 |
| lifeless | see for instances python's dvcs pep for a similar situation | 03:56 |
| poolie | ok | 03:59 |
| poolie | lifeless: btw my previous review for -Dlock did also mention updating the flag documentation | 03:59 |
| poolie | if this is only transitional it may not be a big deal | 03:59 |
| lifeless | poolie: right | 04:00 |
| lifeless | its a bandaid until we can always be asserting | 04:00 |
| lifeless | poolie: have I mentioned my little aws gui ? | 04:00 |
| poolie | no | 04:00 |
| lifeless | bzr branch lp:~lifeless/txaws/client; cd client; bin/aws-status | 04:01 |
| Kilroo | 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:13 |
| lifeless | heh :( | 04:15 |
| Kilroo | Now it's just a question of exactly how I'm going to use it. | 04:15 |
| helebek | hi all, anybody using bzr on windows? I need some help, please. | 04:28 |
| lifeless | helebek: ask your question :) | 04:29 |
| sidnei_ | helebek: ask, and an answer you shall receive. | 04:29 |
| lifeless | poolie: let me know what you thnk of the aws gui | 04:29 |
| helebek | 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 |
| helebek | thank you, btw | 04:31 |
| sidnei_ | helebek: can you connect to the host with putty? | 04:33 |
| helebek | yes I can connect with putty and plink | 04:33 |
| helebek | With sftp://python script giving the error is transport.py (line 213). It says "AttributeError: 'str' object has no attribute 'get' " | 04:34 |
| sidnei_ | oh, yikes. might be a known issue. lifeless? | 04:34 |
| helebek | 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:36 |
| poolie | Kilroo: that kind of sucks, can you file a bug please? javierder is working on it quite actively | 04:37 |
| Kilroo | I think there's already a bug on it, actually. | 04:38 |
| poolie | 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 |
| poolie | it may marginally improve load time | 04:38 |
| poolie | and some of the files are getting small | 04:38 |
| poolie | any conceptual objections, and also | 04:38 |
| Kilroo | No, wait. That might have been for spaces in a url you're trying to pull from. | 04:38 |
| Kilroo | I'll check, and either file or comment as appropriate | 04:39 |
| lifeless | poolie: conceptual objection: its mixing paint :P. | 04:39 |
| poolie | i vaguely recall implementation problems with python (pyc files?) when a directory module turns into a file | 04:39 |
| lifeless | poolie: the other transform is a problem | 04:39 |
| lifeless | foo.pyc is found before foo/__init__.pyc | 04:39 |
| Kilroo | 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 |
| poolie | so you want the base class separate from the text version? | 04:40 |
| poolie | 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:40 |
| lifeless | I think it is cleaner, particularly when we expect dramatically different implementations aorund | 04:41 |
| lifeless | e.g. gtk | 04:41 |
| lifeless | Kilroo: please be sure to file a bug on bzr-eclipse | 04:41 |
| lifeless | poolie: " | 04:42 |
| lifeless | poolie: " | 04:42 |
| lifeless | Reporting suggestions through the bug tracker is fine, though if they're | 04:42 |
| lifeless | likely to be controversial or require extensive discussion it's better | 04:42 |
| lifeless | to go to the list. (This one doesn't.)" | 04:42 |
| lifeless | poolie: ^ thats why I want to keepreviews on the list :) | 04:42 |
| poolie | lifeless: so the subdirectory is a nonissue you think? | 04:47 |
| poolie | why? | 04:47 |
| poolie | well, actually | 04:48 |
| poolie | there are a few related issues | 04:48 |
| poolie | 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 |
| poolie | some people may want to be involved but not subscribed to all bugs | 04:49 |
| poolie | bugs are just linear unthreaded and not so good for long conversations | 04:49 |
| poolie | and it's good for a bug to just contain a summary of what needs to be done not the full discussion | 04:50 |
| poolie | personally i mostly agree with most of them | 04:50 |
| poolie | the third doesn't apply to code reviews which are threaded (though they may be inferior to mail in other ways) | 04:51 |
| poolie | regarding the first and last, i would agree that general discussion should be separate from discussing a particular patch | 04:51 |
| poolie | but that's true on the list as well | 04:51 |
| lifeless | the existence of code isn't a reliable separator for those things | 04:52 |
| lifeless | how often do we have a thread turn into a patch, or vice verca | 04:52 |
| Kilroo | I find that question moderately intriguing. | 04:54 |
| lifeless | 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:54 |
| lifeless | back shortly, lunchy style break time | 04:57 |
| lifeless | poolie: did you give aws-status a spin? | 06:54 |
| poolie | ew | 06:59 |
| poolie | lifeless: not yet, are you really keen that i do? | 07:00 |
| poolie | i guess so or you wouldn't be asking... :) | 07:00 |
| lifeless | well, I know that activation energy is the large thing usually | 07:03 |
| lifeless | 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:04 |
| poolie | it may work better if i'm already in aws-mode | 07:09 |
| poolie | at the moment i've been in email mode striving for finishing-ui-mode | 07:09 |
| lifeless | :) | 07:09 |
| poolie | now interrupted by shops-mode | 07:09 |
| poolie | and, i may not return this afternoon actually | 07:09 |
| poolie | so have a good weekend if i don't see you | 07:09 |
| lifeless | you too | 07:09 |
| poolie | bug me about it again | 07:09 |
| lifeless | you can be sure of that :) | 07:09 |
| lifeless | did you fly in this morning? | 07:10 |
| jml | 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 |
| ubottu | Launchpad bug 310347 in launchpad-code "Temporary "Could not install revisions" error" [High,Triaged] | 07:13 |
| spiv | jml: added a spare comment ;) | 07:18 |
| jml | spiv: thanks :) | 07:18 |
| lifeless | hmm, evo quit by itsself. fun | 07:20 |
| lifeless | wish me luck, that batch of hpss patches is wending its way up to pqm now | 07:41 |
| jml | lifeless: good luck. | 07:48 |
| jml | spiv: I just sent a patch to the mailing list that you might approve of. | 07:52 |
| lifeless | jml: bazaar ? | 08:07 |
| jml | lifeless: yeah. | 08:08 |
| jml | lifeless, spiv: can one of you two please land that for me? | 08:15 |
| jml | I wonder if I should try to get pqm privs for bzr. | 08:15 |
| === dereine[OFF] is now known as dereine | ||
| spiv | jml: I can do that now, sure. | 08:21 |
| jml | spiv: thanks. | 08:21 |
| spiv | jml: I only held off because I wondered if perhaps you already had privs :) | 08:21 |
| jml | spiv: I'm pretty sure I don't. (Is there a way to find out, other than submitting?) | 08:22 |
| spiv | jml: ask lifeless (or equiv. pqm admin) | 08:22 |
| lifeless | jml: ask spm | 08:28 |
| lifeless | night all | 08:28 |
| jml | ok. thanks. | 08:28 |
| jml | lifeless: g'night. | 08:28 |
| spm | lifeless: too late I'm not here.... oops. | 08:28 |
| spm | damn. shouldn't have responded. | 08:28 |
| spm | jml: actually - that is something best sent via rt. if only so that we have the audit trail if you ken. | 08:29 |
| lifeless | spm: asking *about* != asking for | 08:30 |
| jml | spm: yeah, although right now I'm only interested in finding out whether I have permissions. | 08:30 |
| jml | spm: and I'd rather just submit a branch than file an RT to figure that one out :) | 08:31 |
| spm | jml: :-) and no, you dont have access | 08:32 |
| jml | spm: ta | 08:32 |
| lifeless | and it landed, woo | 08:49 |
| spiv | jml: pqm got a conflict, presumably with what lifeless just landed, resolving and firing again. | 08:52 |
| jml | spiv: thanks. | 08:52 |
| lifeless | spm: presumably :P | 08:53 |
| lifeless | bah | 08:53 |
| lifeless | spiv: ^ | 08:53 |
| lifeless | spiv: also, way less roundtrips. We're under 9! | 08:53 |
| spiv | lifeless: Nice. Very nice! | 08:56 |
| lifeless | not stacked sadly | 09:10 |
| lifeless | anyhoo next week I want us to pair | 09:10 |
| lifeless | and figure out sketches for getting the rest down | 09:11 |
| * igc dinner | 09:12 | |
| === dereine is now known as dereine[OFF] | ||
| === dereine[OFF] is now known as dereine | ||
| gnomefreak | is there a way to rename a branch or just push revision with new name? | 11:57 |
| Peng_ | gnomefreak: Just...rename the directory with your standard "mv" or whatever. | 11:58 |
| gnomefreak | Peng_: that would consit of sshing into launchpad right? if so how | 11:59 |
| Peng_ | gnomefreak: Oooh, Launchpad. Can't you do it from the web UI? | 12:00 |
| gnomefreak | checking | 12:00 |
| gnomefreak | under change details is what i want i think | 12:01 |
| gnomefreak | Peng_: thanks it worked | 12:02 |
| Peng_ | :) | 12:03 |
| === dereine is now known as dereine[OFF] | ||
| === dereine[OFF] is now known as dereine | ||
| wgrant | Hmmm. 'bzr revert' doesn't seem to back changes up if the file is involved in a conflict caused during a pull. | 12:27 |
| wgrant | 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? | 12:28 |
| === dereine is now known as dereine[OFF] | ||
| === dereine[OFF] is now known as dereine | ||
| RAOF | Hm. bzr-git is now at 10 minutes CPU time and 2GiB RAM useage, but it looks like it's a-workin. | 12:59 |
| * RAOF thanks jml for the extra GB of ram. | 13:00 | |
| RAOF | On the plus side, the ram usage is steadily decreasing. | 13:04 |
| === dereine is now known as dereine[OFF] | ||
| bac | hi, is there a PPA for bzr-gtk? | 14:11 |
| lifeless | wgrant: we record the hash of files output during merge | 14:13 |
| wgrant | bac: https://edge.launchpad.net/ubuntu/+ppas?name_filter=bzr-gtk suggests that there are several official-looking ones. | 14:13 |
| lifeless | wgrant: so we can revert cleanly without backups then | 14:13 |
| wgrant | lifeless: Right, I've since looked through that code thoroughly. | 14:13 |
| bac | thank wgrant | 14:13 |
| wgrant | lifeless: Bug #370334 | 14:13 |
| ubottu | Launchpad bug 370334 in bzr "Reverting a file conflicted from a pull loses changes" [Undecided,New] https://launchpad.net/bugs/370334 | 14:13 |
| wgrant | lifeless: But you can't revert to the files immediately before the merge. | 14:14 |
| wgrant | lifeless: Because they were uncommitted changes. | 14:14 |
| lifeless | wgrant: mark it confirmed high :) | 14:16 |
| bac | wgrant: doesn't look like any of those support bzr 1.14. | 14:17 |
| wgrant | lifeless: Thanks! | 14:17 |
| wgrant | lifeless: Er, but I have no bzr Importance privileges. | 14:17 |
| lifeless | wgrant: join the team :P | 14:18 |
| lifeless | or remind me tomorrow; its late here | 14:18 |
| wgrant | lifeless: I was quite surprised to see you around at this hour, yes... | 14:18 |
| wgrant | abentley: Thanks. | 14:41 |
| abentley | wgrant: np. Of course, this means I have no plausible deniability when people ask why this bug isn't fixed. :-) | 14:41 |
| wgrant | abentley: Heh. | 14:42 |
| === ja1 is now known as jam | ||
| === dereine[OFF] is now known as dereine | ||
| === dereine is now known as dereine[OFF] | ||
| Kamping_Kaiser | hm... Woudl be nice if bzr fell back to LC_CTYPE=C if nothing else was set :/ | 16:01 |
| Peng_ | What does it do instead? | 16:06 |
| GaryvdM | I broke my windows installation, and I'm having some difficulty getting ssh working . Putty is setup, PageANT is running with a new private key, I've uploaded the new public key. | 16:10 |
| GaryvdM | But I get bzrlib.errors.ConnectionReset: Connection closed: please check connectivity and permissions | 16:10 |
| GaryvdM | How can I debug this? | 16:11 |
| Kamping_Kaiser | Peng_, crashes. (this is 0.8, its possible it Just Works in the current release) | 16:24 |
| Peng_ | Kamping_Kaiser: 0.8 is *incredibly* old. | 16:24 |
| Kamping_Kaiser | Peng_, yes, shipped in Ubuntu 6.06 (which this server is running) :/ | 16:26 |
| GaryvdM | Hmm: I just noticed this error: http://pastebin.com/d3fc9a661 | 16:27 |
| GaryvdM | Maybe I need to delete all my keys on lp and start over. | 16:28 |
| Peng_ | Kamping_Kaiser: The PPA might still support 6.06. https://launchpad.net~bzr/+archive | 16:29 |
| Peng_ | Err./ | 16:29 |
| Peng_ | Kamping_Kaiser: https://launchpad.net/~bzr/+archive | 16:29 |
| Peng_ | I blame my Internet connection! :P | 16:29 |
| Kamping_Kaiser | Peng_, i'll check, thanks. | 16:30 |
| GaryvdM | Yhea - ssh working now. :-) | 16:32 |
| === ja1 is now known as jam | ||
| === dereine[OFF] is now known as dereine | ||
| LarstiQ | beuno: bzr 1.14 is in the non-beta ppa now. | 18:38 |
| rockstar | abentley, hey. | 18:54 |
| abentley | rockstar: hey | 18:55 |
| rockstar | format_registry.aliases() returns a set with three strings in it. What format strings are those for? Repositories? | 18:56 |
| abentley | rockstar: You're talking about the bzrdir format registry? | 18:56 |
| === dereine is now known as dereine[OFF] | ||
| rockstar | abentley, ah, that should make it obvious... | 18:56 |
| === Leonidas_ is now known as Leonidas | ||
| jam | abentley: ping | 19:07 |
| abentley | jam: pong | 19:08 |
| jam | did you still want to chat about whatever it was yesterday? | 19:08 |
| abentley | jam: sure. | 19:09 |
| === dereine[OFF] is now known as dereine | ||
| === GaryvdM_ is now known as GaryvdM | ||
| S11001001 | rebase hackers: why is rebase trunk 1.13-compatible and 1.15-compatible, but not 1.14? | 20:02 |
| LarstiQ | S11001001: because 1.14 has the same api as 1.13? | 20:02 |
| LarstiQ | assuming it checks api compatibility, not bzr version | 20:03 |
| S11001001 | api | 20:03 |
| LarstiQ | there you have it then :) | 20:04 |
| S11001001 | Unable to load plugin 'rebase'. It requested API version (1, 15, 0) of module <module 'bzrlib' from '/usr/local/lib/python2.6/site-packages/bzrlib/__init__.pyc'> but the minimum exported version is (1, 14, 0), and the maximum is (1, 14, 0) | 20:04 |
| S11001001 | and bzrlib/__init__.py has api_minimum_version = (1, 14, 0) | 20:04 |
| LarstiQ | S11001001: right, that is a mistake and I'm expecting a 1.14.1 release for it | 20:04 |
| S11001001 | okay, thanks LarstiQ | 20:05 |
| LarstiQ | S11001001: if you're willing, you can safely edit that (1, 14, 0) into (1, 13, 0) | 20:05 |
| S11001001 | sounds good | 20:07 |
| S11001001 | merci | 20:07 |
| jonnydee1 | Hi, I've just checked out (lightweight) the rebase trunk from http://people.samba.org/bzr/jelmer/bzr-rebase-old/trunk because the version available in Jaunty seems not to be compatible with bzr 1.14. | 20:50 |
| jonnydee1 | The last trunk's revision, however, seems not to be compatible with 1.14, either, because it already requires bzr 1.15. So I tried to get a previous revision using 'bzr pull -r -2' and got the following error message: | 20:50 |
| jonnydee1 | bzr: ERROR: Cannot lock LockDir(http://people.samba.org/bzr/jelmer/bzr-rebase/trunk/.bzr/branch/lock): Transport operation not possible: http does not support mkdir() | 20:50 |
| jonnydee1 | Anyone any idea? | 20:51 |
| LarstiQ | BasicOSX: what are the 1.14.1 plans? | 20:51 |
| LarstiQ | jonnydee1: the error you get because in a lightweight checkout, 'pull' goes to what you're bound to, being http://people.samba.org/.., which is not writable. | 20:51 |
| LarstiQ | jonnydee1: you can use `bzr revert` instead to make the tree state be the same as in a prior revision. | 20:52 |
| jonnydee1 | So a pull is not a readonly operation? | 20:52 |
| LarstiQ | jonnydee1: however, bzr 1.14 shoud have api compatility 1.13, instead of the 1.14 it has | 20:52 |
| jonnydee1 | @LarstiQ: Thanx for your hint | 20:52 |
| LarstiQ | jonnydee1: so you can change bzrlib/__init__.py, (1, 14, 0) -> (1, 13, 0) | 20:53 |
| LarstiQ | jonnydee1: if pull was a readonly operation, how would it help you? :) | 20:53 |
| jonnydee1 | I mean readonly in terms of "do not modify the repository I pull from" | 20:54 |
| LarstiQ | jonnydee1: the point being that pull operates on the branch, which you don't have access to in this case. | 20:54 |
| LarstiQ | jonnydee1: in general, I think it's a very bad idea to use lightweight checkouts over high latency links. | 20:54 |
| BasicOSX | LarstiQ: 1.14.1 milestone created, plan? tag bugs to that milestone and discuss when devs happy with bug list for me to make a release? | 20:54 |
| jonnydee1 | BTW: "bzr revert -r -2" also gives me a bzr: ERROR: Cannot lock LockDir(http://people.samba.org/bzr/jelmer/bzr-rebase/trunk/.bzr/branch/lock): Transport operation not possible: http does not support mkdir() | 20:55 |
| LarstiQ | BasicOSX: sounds good. My vote is for the list of changes to be just the api version, we can roll a 1.14.2 later | 20:55 |
| LarstiQ | jonnydee1: ah hmm. | 20:55 |
| BasicOSX | LarstiQ: been out of loop for a couple days (real job stuff) 1.14.1 regression release? | 20:56 |
| jonnydee1 | ok, but I understood that a pull on a lightweight checkout tries to pull into the remot branch :) -- seems pretty logical regaring the fact that a lightweight checkout doesn't have history information...sorry, my fault | 20:56 |
| LarstiQ | jonnydee1: I suggest you `bzr reconfigure --checkout` | 20:57 |
| LarstiQ | BasicOSX: basically. | 20:57 |
| BasicOSX | :-( I'm going to get another condolence email from RMS! | 20:58 |
| LarstiQ | BasicOSX: practice makes perfect! | 20:58 |
| jonnydee1 | LarstiQ: This gives me a bzr: ERROR: KnitPackRepository('file:///home/jonnydee/.bazaar/plugins/rebase/.bzr/repository/') is not compatible with KnitPackRepository('http://people.samba.org/bzr/jelmer/bzr-rebase/.bzr/repository/') different rich-root support | 20:58 |
| jonnydee1 | I will just re-checkout the branch | 20:59 |
| LarstiQ | BasicOSX: and besides, dealing with issues is more important than never making a mistake. | 20:59 |
| BasicOSX | I was joking, it's just funny to get email from RMS on regression releases that say "Condolences on the release" | 21:00 |
| LarstiQ | :) | 21:00 |
| BasicOSX | LarstiQ: quick scan of ML doesn't show me the discussion of the regression, what should up? installing from source broken on Windows? | 21:00 |
| LarstiQ | BasicOSX: let me check. | 21:01 |
| BasicOSX | what should up = what showed up ? | 21:01 |
| LarstiQ | BasicOSX: the api_minimum_version thread | 21:02 |
| LarstiQ | BasicOSX: which is breaking plugins | 21:02 |
| BasicOSX | oh? hmm, I remember that -and- it's my fault, 1.14 should have api of 1.13? 1.14? | 21:03 |
| * LarstiQ applies qannotate to bzrlib/__init__.py | 21:03 | |
| BasicOSX | http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/57260 <- that thread, right LarstiQ ? | 21:04 |
| LarstiQ | BasicOSX: yup | 21:04 |
| BasicOSX | Did a bug ever get opened for this issue? | 21:07 |
| BasicOSX | does not look like it | 21:07 |
| LarstiQ | I don't think we really need it, but that's my opinion. | 21:07 |
| LarstiQ | BasicOSX: looking at the diff, between rc2 and final api version changed from (1, 13, 0) to (1, 14, 0). So yeah, roll it back to (1, 13, 0) | 21:08 |
| jonnydee1 | LarstiQ: Will that change 'rollback from (1, 13, 0) to (1, 14, 0)' be included in 1.14.1? Will it resolve the 'rebase' problem? | 21:09 |
| LarstiQ | jonnydee1: yes. | 21:15 |
| === dereine is now known as dereine[OFF] | ||
| jonnydee1 | LarstiQ: cool!!! :D You guys are great!!! Thanx for your help!!! | 21:20 |
| LarstiQ | jonnydee1: np :) | 21:22 |
| jonnydee1 | Sorry for annoying you, but I just tried out the new "bzr mv --auto" feature. I created an empty branch, added a text file to it and committed it to the branch. Then I created a new directory, and moved the text file into this new directoy. Afterwards, I did a "bzr mv --auto"... | 21:26 |
| jonnydee1 | Which resulted in a | 21:27 |
| jonnydee1 | => new | 21:27 |
| jonnydee1 | test.txt => new/filew.xml | 21:27 |
| jonnydee1 | then I did a 'bzr st' and got a traceback. | 21:27 |
| jonnydee1 | message: "bzr: ERROR: exceptions.IndexError: list index out of range" | 21:28 |
| jonnydee1 | I think it's because bazaar doesn't add the (still unversioned) directory first... | 21:29 |
| jonnydee1 | (btw: in my case the directory was called 'new') | 21:30 |
| LarstiQ | jonnydee1: a bug report is not annoying :) | 21:31 |
| * LarstiQ tries to reproduce | 21:31 | |
| jonnydee1 | ok :) | 21:31 |
| LarstiQ | jonnydee1: I believe I followed your recipe exactly, but no traceback. | 21:32 |
| * LarstiQ is on bzr.dev | 21:32 | |
| jonnydee1 | ok, I will redo my steps again -- just to make sure I can reproduce this behavior... | 21:33 |
| GPHemsley | I just issued the command `bzr log -v -rthread:` to see what it did, and I got a Python traceback | 21:34 |
| GPHemsley | Is this a known bug? | 21:34 |
| LarstiQ | GPHemsley: looms? | 21:35 |
| GPHemsley | LarstiQ: What about them | 21:35 |
| GPHemsley | ? | 21:35 |
| jonnydee1 | LarstiQ: I can reproduce this behavior | 21:35 |
| LarstiQ | GPHemsley: I'm not familiar with thread: | 21:36 |
| LarstiQ | jonnydee1: can you capture it in a script that I could run? | 21:36 |
| GPHemsley | LarstiQ: I'm not, either, but I definitely shouldn't be getting a Python traceback | 21:37 |
| jonnydee1 | Of course, I am just doing this... | 21:37 |
| LarstiQ | GPHemsley: true, true :) | 21:37 |
| LarstiQ | jonnydee1: cool | 21:37 |
| LarstiQ | GPHemsley: when I run that, I get: No namespace registered for string: u'thread:' | 21:37 |
| LarstiQ | GPHemsley: which is supotimal (and reported), but not a traceback | 21:38 |
| GPHemsley | LarstiQ: What version? | 21:38 |
| LarstiQ | GPHemsley: bzr.dev | 21:38 |
| * GPHemsley is on 1.13.1 | 21:38 | |
| * LarstiQ tries with 1.13 | 21:38 | |
| GPHemsley | Perhaps it was fixed already? | 21:38 |
| LarstiQ | doesn't happen there either. | 21:38 |
| GPHemsley | hmm | 21:39 |
| LarstiQ | GPHemsley: does the traceback show it happens in plugin code? | 21:39 |
| GPHemsley | this is the error: | 21:39 |
| GPHemsley | bzr: ERROR: exceptions.AttributeError: 'BzrBranch7' object has no attribute 'get_loom_state' | 21:39 |
| GPHemsley | plugins/loom/revspec.py | 21:39 |
| GPHemsley | lines 44 and 51 | 21:40 |
| GPHemsley | So, I think that's a yes | 21:40 |
| jonnydee1 | LarstiQ: Here is my script: "bzr init trunk && cd trunk && echo Hello World! > test.txt && bzr add && bzr ci -m "Import." && mkdir new && mv test.txt new/filew.xml && bzr mv --auto && bzr st" | 21:40 |
| === dereine[OFF] is now known as dereine | ||
| LarstiQ | jonnydee1: thanks, that does blow up on me. | 21:42 |
| jonnydee1 | np ;) | 21:42 |
| LarstiQ | and I thought I did that manually, hmm. | 21:42 |
| jonnydee1 | should I report a bug? | 21:42 |
| LarstiQ | jonnydee1: yes please :) | 21:43 |
| jonnydee1 | ok - thanks again for your feedback | 21:43 |
| GPHemsley | LarstiQ: I filed a bug: https://bugs.launchpad.net/bzr/+bug/370545 | 21:44 |
| ubottu | Launchpad bug 370545 in bzr "`bzr log -v -rthread:` fails with AttributeError" [Undecided,New] | 21:44 |
| LarstiQ | GPHemsley: I'm reassigning it to bzr-loom | 21:45 |
| GPHemsley | LarstiQ: Already did :) | 21:45 |
| LarstiQ | doh :) | 21:45 |
| GPHemsley | So, what I really wanted was to filter log output for only specific files/directories | 21:46 |
| GPHemsley | Is that feature not available? | 21:46 |
| LarstiQ | GPHemsley: `bzr log file`? | 21:47 |
| GPHemsley | well, more specifically, a specific directory and down | 21:47 |
| LarstiQ | GPHemsley: there are some shortcomings, that might be one of them. | 21:47 |
| LarstiQ | GPHemsley: Ian has been working on that lately iirc | 21:48 |
| GPHemsley | if I do `bzr log .` or `bzr log ..`, I only gives me the results that specifically affected the directory itself... not all the files in it | 21:48 |
| GPHemsley | s/I/it/ | 21:48 |
| * LarstiQ fails to find the relevant emacs page | 21:49 | |
| jonnydee1 | LarstiQ: I've filed the "bzr mv --auto" bug: https://bugs.launchpad.net/bzr/+bug/370551 | 21:56 |
| ubottu | Launchpad bug 370551 in bzr ""bzr mv --auto" fails with "bzr: ERROR: exceptions.IndexError: list index out of range"" [Undecided,New] | 21:56 |
| LarstiQ | jonnydee1: thanks | 21:56 |
| * LarstiQ calls it a night | 21:57 | |
| jonnydee1 | no problem :) | 21:57 |
| LarstiQ | GPHemsley: I couldn't find a wiki page or bug concerning that atm, maybe Ian mentioned it on t elist. | 21:57 |
| GPHemsley | k | 21:57 |
| GPHemsley | thanks for your help | 21:57 |
| === dereine is now known as dereine[OFF] | ||
| GPHemsley | Is there a way to customize the colors used for bzr cdiff? | 22:19 |
| jonnydee1 | Hi, just an idea: wouldn't a "bzr-portable-1.xx-x.exe" be a better name than a "bzr-nonadmin-1.14-1.exe"? (Just to make clear it can also be installed on a USB stick.) | 22:41 |
| jonnydee1 | (erm, I wanted to write "bzr-nonadmin-1.xx-x.exe" instead of "bzr-nonadmin-1.14-1.exe") | 22:42 |
| BasicOSX | darn it jam, stop hog'n PQM queue! :-P | 23:02 |
| === dereine[OFF] is now known as dereine | ||
| === BasicOSX changed the topic of #bzr to: Bazaar version control system | 1.14.1 released 01 May, 2009 | 1.13.2 released 28 April, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!