[00:00] Oh THAT one. right. /me recalls the pain. oh the pain. shared pain at that. [00:03] lifeless: I should package autolp if the upgrade-branch-format command is something you're recommending to others. [00:04] Having lots of RAM to throw at Loggerhead is fun. [00:04] Though, if it's only something spm can usefully use, maybe it's not a big deal yet. It only has that feature right now, so not terribly useful to package it yet. [00:06] jkakar: I'm pointing people at spm :) [00:06] spm: anyhow, that the most likely cause for the failed branches; reconcile won't fix it. [00:07] lifeless: Excellent. :) [00:07] jkakar: running the fix script the bug has attached to it when a missing rev error happens would be nice (or even just do it to all stacked branches before starting the upgrades) [00:07] lifeless: Would it be worth making the script catch missing revision exceptions and continue on, or should it blow up and stop? [00:07] lifeless: Ah ha, okay. I'll look at doing that. [00:08] the fix script is 10 lines of python or so [00:08] Cool. [00:08] so for branch in branches: if branch.get_stacked_url(): fixmenow; [00:08] for branch in branches: upgrade... [00:10] I think it's "get_stacked_on_url". :P [00:14] Are there any rebase users around? I'm seeking someone to discuss my "bzr rebase: Change behaviour to be as if --always-rebase-mergesspecified, remove outright the current default mode" email with [00:17] maxb: discarding merges can be very useful [00:17] we support that in bzr core; I'm not sure why you'd want to remove it from rebase (also are you aware its now 'bzr-rewrite') [00:17] q: is it adviseable to use the 'smart-server' in a high-volume production environment? The advantage of bzr+ssh = speed/encryption and the advantage of bzr+http(s) = encryption/flexible user management, correct? I'm thinking about setting up bzr+http (ro) and bzr+https (rw) and connect apache to a small db (test) or ldap (production) instead of using bzr+ssh and just would like a small piece of advice _before_ I start setting it up. [00:17] SWAT: the smart server can work over http [00:18] SWAT: so you've presented a false dichotomy ;) [00:18] lifeless: The problem with the feature as currently implemented is that it discards revisions solely based on ancestry. What it should/could do, to be correct, is discard revisions only if a merge results in there being no changes to commit. [00:18] maxb: perhaps [00:19] maxb: though I don't think I agree [00:20] You don't think that it's wrong that rebase is lossy by default? [00:20] rebase is by definition lossy [00:20] its its raison d'etre [00:22] Well... far more lossy than the basic concept of rebasing inherently includes [00:23] anyhow, a merge that includes something from the branch being rebased *on* should be discarded. [00:23] whether or not there are textual changes is perhaps a case for a warning. [00:23] Yes.... but only if there aren't relevant textual changes remaining on merging it [00:24] maybe [00:24] I think it really depends on the exact change [00:24] and what it means semantically. [00:24] lifeless: ah, right, thanks. Let me put it differently: is it adviseable to use bzr+http(s) instead of bzr+ssh or is it all neglectable? [00:25] maxb: it probably needs to be put way down at the bottom of the rebase in fact, for the case of a merge already in the base. [00:25] maxb: OTOH a merge from a branch not merged to base, should be kept. [00:25] SWAT: shouldn't be any significant differences in performance. [00:25] SWAT: if there are, they are bugs [00:26] lifeless: thanks a lot. I'll leave you to your other discussion(s). Cheers [00:26] I don't think it makes sense to try to replay merges out-of-order if that's what you're suggesting - the merge is on top of other changes on your branch being rebased, and is likely to have textual dependencies on them [00:27] maxb: I'm not sure I was totally clear about the case being discussed [00:29] Well, I'm approaching this from the PoV of "It's never OK to discard a merge revision purely based on ancestry, you have to see if there are relevant textual changes" - because the act of resolving conflicts when the merge was done may include making valuable changes. [00:30] By way of a specific example: we had a Launchpad branch for a newer python version. When a new script was added on trunk, the shebang had to be changed as part of merging the addition to the branch. [00:30] A purely ancestry-based approach would silently lose that sort of change [00:33] maxb: but thats my example [00:33] ? [00:33] maxb: if you have the rev merged earlier you need the shebang earlier too [00:35] hmm. The idea of reordering changesets instead of just replaying the graph maintaining its shape is scary [00:35] maxb: rebasing anything where revisions merged higher up that are already in the new base is non trivial. [00:36] maxb: (consider the typical loom usecase) [00:36] maxb: where what you are rebasing is just a non-linear but still discrete subgraph, its easy. [00:36] this is one of the problems with merges and rebase. [00:59] spiv: can I beg you to fix pqm-submit today? It would save me reinventing yoour changes. [00:59] lifeless: ok [01:00] lifeless: although I would hope you'd choose to build on my changes, rather than reinvent them... [01:00] spiv: So would I. [01:01] lifeless: thanks for the tip on: for dir in `ls $1`; I got it working, but can't get it to work as a Bash alias. Any ideas? [01:06] eric_f: I'd make a small bash script [01:07] you might also look at 'bzr-removable', it might fit your needs (if I'm guessing right) [01:08] Wow. "bzr check" on a 1.14 copy of MySQL is using more than 4 gigs of RAM. [01:09] lifeless: I'm doing this: [01:09] for dir in `ls $1`; do if [ -e ${dir}/.bzr ]; then echo ${dir}; echo --------------------; bzr status ${dir}; echo; fi done; [01:09] Peng: it checks your RAM *and* your branch! [01:09] i want to alias that so I don't have to type it all the time [01:10] eric_f: put it in a script in your path [01:10] then you don't have to type it all the time [01:11] spiv: It's checking my swap, too. [01:11] mem [01:11] disk [01:11] content [01:11] \o/ [01:11] profit [01:13] But I don't want to pay for more RAM. [01:14] This is really amazing, though. On a 32-bit machine with a 2a repo, checking MySQL isn't a big deal. Maybe 500-600 MB of RAM. [01:14] 2a rocks. [01:14] How did we ever live with the pre-2a formats? :P [01:20] is there any way in a central repository setup to have the repository automatically update its tree on commit? the push-and-update plugin looks like a local hook, and the automirror plugin seems to only want to push to a second repo [01:23] Currently RAM+swap is approaching 7 GB. [01:24] Peng: Machines get more memory all the time. If we don't keep up with that increase, how will we ever compete with Windows? [01:26] Can Canonical send me $70 so I can buy enough RAM to check this repo? :D [01:26] Actually, only $50. I have a little money in my wallet. :P [01:27] Shoulda bought memory back in June like I did, before it shot back up in price :p [01:31] Linkadmin: not really. [01:31] Linkadmin: generally that suggests you are trying to do something in an unusual way [01:31] i just want the working tree to be updated when i do a commit... [01:39] Linkadmin: Why does the central repo need a tree at all? [01:42] Peng: sorry, i meant the branch needs a working copy [01:42] not the repo [01:42] Linkadmin: Why does the central branch need a tree? [01:43] Peng: because i'd like to set up a webserver to point to the docs I'm keeping in version control [01:44] so if i do i.e., bzr init-repo repo ; bzr init repo/branch and then remotely commit to repo/branch, i don't seem to see my updated docs in repo/branches on the server [01:45] Oooh. [01:46] and when I do bzr push, it tells me something about the remote tree not being updated :S [01:49] Linkadmin: working trees are designed for local use, bzr can't update them over remote connections like sftp [01:49] Linkadmin: you may be interested in the bzr-upload or bzr-push-and-update plugins [01:50] spiv: yeah i was looking at that, but those seem to be local hooks, not run on the central repository [01:50] Right. [01:50] which means that the plugins need to be installed on every collaborator's computer, and they all need to use the plugins' commands [01:51] Well, push-and-update hooks into regular bzr push, but yes. [01:51] The simplest solution is to put a cron job on the server that runs "bzr update" every 10 minutes or so. [01:52] i think i'll probably set up a second branch and have automirror push to that branch. Since automirror is post_commit, that means it's run from the central repo, right? [01:52] If the central branch is only written to via a smart server (e.g. bzr+ssh), then in principle you could write a simple plugin to hook the Branch.post_branch_tip_change event and then run "bzr update" from that. [01:53] But I wouldn't be surprised if there are a bunch of annoying details that make that harder than it should be... [01:53] i was thinking about doing that too yeah [01:53] I'd be happy to help if you want to do that, though. [01:53] but it sounds like automirror would be a safer choice if it can run on commit on the repo, and not on individual systems [01:54] post_commit is run where the commit happens -- i.e. the computer where 'bzr commit' is running, not on the repo. [01:54] oh man [01:55] The right server-side hook is Branch.post_change_branch_tip [01:55] but wait... [01:55] https://bugs.launchpad.net/bzr-email/+bug/307988 [01:55] Launchpad bug 307988 in bzr-email "Central repository email?" [Undecided,Invalid] [01:55] this runs from the central server [01:55] oh i see [01:55] different hooks, ok [01:56] Yes, bzr-email uses that hook [01:56] do you know if automirror does? I'll go look for the code, brb [01:56] (Although it will fallback to post_commit for ancient bzr versions) [01:57] It appears not, but it's probably not hard to update it. [01:58] Linkadmin: give me 10 minutes, I'll whip up a patch, this looks pretty straightforward [01:58] w00t w00t [02:11] Linkadmin: lp:~spiv/bzr-automirror/use-new-hook [02:12] i was just looking at that :) [02:12] i'll try it out right now [02:13] just to recap my plan, i'll bzr init-repo repo ; bzr init repo/branch1 ; bzr init repo/branch2, then in branch1/.bzr/branch/branch.conf i'll tell it to post_commit_update (or whatever the setting is) to branch2, and when I commit over bzr+ssh remotely, that hook will run properly? [02:13] sure. Dunno why you need a second branch thouh. [02:14] well because i don't think automirror will properly push the branch into its own working copy without problems, right? [02:15] uh [02:15] so I would just call tree.update() from the post tip change hook on the server [02:16] lifeless: the "just" there hides a few details, but sure :) [02:16] I guess params.branch.bzrdir.open_workingtree().update() would probably work. [02:17] then why doesn't bzr do that by default? It does it for local branches but won't do it on remotes... [02:17] with try: except errors.NoWorkingTree:pass [02:17] Linkadmin: because in the general case it won't work. [02:17] Linkadmin: if you have conflicts, or the tree is locally edited, there is no UI for the person pushing to fix issues with it. [02:18] gotcha [02:18] And we'd need to define the network protocol for reporting those issues, etc. [02:18] makes sense [02:18] so it will probably come at some point i guess [02:18] In your case, you're always expecting tree.update() to work because there should never be any local changes. [02:18] Linkadmin: I doubt it. [02:19] Linkadmin: its not on anyones todo list, and I know of plenty of cases where doing it would be very much the wrong think. [02:19] is there a roadmap for features for future development? [02:19] s/think/thing/ [02:24] lifeless: as part of patch piloting, please chase up contributor agreements where needed [02:24] and add them to that team [02:24] http://pastebin.ubuntu.com/326532/ <- is that ok for NEWS entry? [02:24] thx a ton for the help guys. Gonna try out that hook spiv. [02:24] poolie: I know [02:24] i know you may already know this [02:24] mwhudson: itym UNICODE(tm) [02:24] :-) [02:24] heh [02:24] mwhudson: looks fine to me [02:25] but seriously, good, except that I'd drop the final . from the url [02:25] putting the tm mark in would have a certain irony [02:25] to stop lp spazzing out [02:25] Or wrap the URL in <> [02:26] yes [02:26] what should i set public_location and submit_to to? [02:27] http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev [02:27] submit branch [02:27] public_location should be something like: [02:28] actually [02:28] it should default to push_location [02:28] which is fine [02:28] if it doesn't [02:28] public_branch = lp:~mwhudson/bzr [02:28] oh sorry [02:28] public_branch:policy = appendpath [02:28] i meant the email address [02:28] pqm@bazaar-vcs.org [02:29] thanks [02:33] that didn't work [02:33] All lines of log output:Sender not authorised to commit to branch bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/ [02:33] oh [02:33] trailing slash ftl [02:34] nope [02:34] All lines of log output:Sender not authorised to commit to branch bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev [02:34] igc: do you have a specific definition of "gateway pattern"? [02:34] spm: halp [02:34] mwhudson: yo [02:35] oh right. I see. hrm. [02:35] spm: i can't seem to commit to bzr [02:35] mwhudson: do a dry run and pastebin it [02:35] mwhudson: http://, not bzr+ssh:// ? [02:36] http://pastebin.ubuntu.com/326540/ [02:36] lifeless: i suspect that until lp has a concept of mp assignee [02:36] it will be easier not to have pilots carry over responsibility for things they started on [02:36] spiv: ah, seems happier [02:37] poolie: I think we should try it and see. [02:37] poolie: handoffs are expensive and will likely fragement discussions [02:37] mwhudson: I also use http for my branch in the pqm submission too, because pqm keeps having trouble with it. I honestly can't remember if that's been sorted or not. [02:38] spiv: mine seems to be getting somewhere [02:38] mwhudson: that good :) [02:41] hi poolie [02:41] poolie: I need to get lunch right now (with my sick daughter) but I'll bbiab [02:42] * igc lunch [03:32] woot, my patch landed in bzr [03:58] guys, how could i create a plugin that automatically format the commit messages in a given way? is there a easy tutorial to create plugins? [04:03] it's certainly possible but i don't know how [04:04] mwhudson: thanks. but now i need to know the "how" part :P [04:05] brmassa: there are some docs [04:05] yes, i was aware i was't being very helpful [04:06] * spiv tries to dig them up [04:08] brmassa: http://bazaar-vcs.org/WritingPlugins seems to be the most helpful link, but I'm sure there's more somewhere, but I'm having trouble finding it :/ [04:08] Well, there's http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/writing_a_plugin.html, but it's pretty short. [04:09] spiv: hmmm thanks! i ll take a better look. i will report back if i get something... [04:12] Ah, there's http://doc.bazaar-vcs.org/developers/plugin-api.html, but it doesn't seem to be linked from anywhere. [04:12] Oh, via Specifications, I see. [04:13] Hmm, the way the docs try to be both sphinx and not-sphinx is a bit confusing. [04:14] poolie: https://code.edge.launchpad.net/~mbp/bzr-usertest/trivial/+merge/7532 - just push :) [04:15] k [04:35] lifeless: i'm going to ask for an sru for all of 2.0.2 into karmic etc [04:35] to get some practice, and to get those fixes in [04:36] cool [04:36] do you want to talk about it first? [04:36] if you like [04:37] not especially [04:37] i thought i'd just file it and then people can comment if they want [04:37] it's been discussed a few time before [04:37] the big question is whether they'll be ok with one sru taking multiple fixes [04:37] and also i guess whether it's sufficiently conservative [04:37] the key thing is 'auditable' [04:38] someone will read the diff === mzz_ is now known as mzz [04:46] Hmm, 2.0.0 -> 2.0.2 diffstat: 54 files changed, 1562 insertions(+), 487 deletions(-) [04:47] But about half of that is in bzrlib/tests/ [04:48] poolie: can I borrow the LEAN book when you've finished it ? [04:56] yes [04:58] lifeless/igc: how about upgrading bzr-usertest to 2a? any objections? [04:58] poolie: sure [04:58] poolie: I've done it locally last week iirc [04:59] poolie: maybe I didn't finish doing the lp dance at that end [04:59] oh maybe not [04:59] 2a comes with lap dances?! [04:59] poolie: JFDI [05:00] our community is all dependent on 2a anyway to get bzr itself [05:02] igc, oh, maybe you wanted to make https://code.edge.launchpad.net/~ian-clatworthy/bzr-usertest/trunk the new trunk? [05:02] suggest you reassign ownership too [05:02] poolie: I'll take a look [05:05] thanks === meoblast001 is now known as ecksvedDAYyahs [05:09] igc, ping me when you're done and i'll do that merge for robert [05:09] poolie: ok === ecksvedDAYyahs is now known as meoblast001 [05:22] poolie: new trunk pushed but I don't think it went smoothly [05:22] poolie: the old branch disappeared? Did you rename it? [05:22] poolie: maybe lp eat it while I was changing the development focus [05:23] ate [05:25] poolie: ah. It's still there under trunk-old and things look ok now [05:26] * lifeless really prefers in place upgrades [05:26] they seem smoother to me [05:39] igc: i haven't looked at the releases yet; there's meant to be one this week, but with john sick and on holidays maybe someone else should do it [05:43] poolie: did you want to do our weekly call today? [05:43] sure [05:43] in 2m is good for me [05:44] poolie: how does 10 minutes sound? [05:46] So... bzr-fastimport [05:46] how do I go about using this? [05:47] igc, cup of tea loaded, call when ready :) [05:47] poolie: now is fine :-) [06:00] I guess I'll need to play with fastimport tomorrow - it looks like it won't be fun [06:03] igc, no, not mine i guess [06:03] done [06:04] poolie: ^ [06:04] k [07:22] igc: are you still here? [07:25] it seems not, I'll send a mail then [07:32] spiv: and where is your pqm-submit work? [07:35] lifeless: a happy coincidence, just pushing an update now that adds tests [07:37] spiv: just land it then. /me rs's the tests. [07:37] lifeless: ok, will do. Thanks! [07:37] spiv: how do you use it though [07:38] lifeless: set pqm_email in locations.conf for the public_location [07:38] hi bialix [07:39] spiv: oh! so I need to edit locations.conf to send in gordon's merge remotely? [07:39] lifeless: then use --ignore-local and specify the submit branch and public branch explicitly via the relevant options. [07:39] (or you can put the pqm_email in your global config...) [07:39] spiv: what do you think of looking up pqm_email on the target branch location ? [07:40] lifeless: I have this in my locations.conf: [07:40] [lp:~*/bzr/] [07:40] pqm_email = Canonical PQM [07:40] lifeless: that sounds reasonable on the face of it. [07:40] ok, that will do. I'll file a bug for the other point. [07:40] lifeless: I can't really remember why I did it this way, to be honest. [07:41] * igc dinner [07:41] lifeless: enjoy! and file bugs, of course :) [07:41] * spiv -> off the evening. [07:41] spiv: thanks [07:51] OK, let's try "bzr check" again with 8 GB of RAM. And I'm not going any higher. [07:52] poolie: did you land that usertest branch? because of the branch dance lp won't say [08:14] hi all ! [08:16] vila: hihi [08:16] vila: --no-strict! :) [08:16] :) [08:17] (as in, I'm hoping you can fix that bug today :P) [08:17] hello vila! you're back! [08:18] lifeless: yeah. got that. No promise, babune is almost red even in its reduced config... [08:19] bialix: hi :) Still fighting jetlag, but getting there, hopefully I'll be able to stay awake today :) [08:19] * bialix hopes you fly from warm sea and good rest ;-) [08:20] vila: I won't ping you today, I promise; just glad you're back [08:20] :) [08:23] * bialix wonders why igc don't use lazy_register for explorer commands [09:59] igc: Hi! [10:02] bialix: Hello! What time is it now in Kiiv? [10:03] OldAl: hi, there is noon now, we're live in +2 timezone [10:03] igc is not here right now [10:04] bialix: Well, left a "hi" for igc, but no reply. [10:07] bialix: OK, 1200 where you live; 2100 in Canberra 1200 +900 = 2100. What part of Ukraine are you at? What is the nearest city? [10:10] bialix: So you are near the Black Sea? [10:19] hi bialix, OldAl [10:19] evening igc [10:20] What is a revision key? I found that term looking at the bzr source code... [10:20] igc: Hi, igc [10:21] igc: I'd like to land my patch for lazy-commands in explorer. I found some use cases for it. I'll wait till weekend if you find the time for review. [10:21] igc: Just had a chat with bialix. [10:21] MvG: revision key? maybe revision-id? [10:22] bialix: No. The one-element tuple (revid,) seems to be /one/ possible form of a revision key, but I assume not the only one. [10:22] * MvG is reading Repository.get_parent_map [10:22] where isone-item tuple, there is possible multiple-items tuples [10:23] yes, but with what meaning? [10:23] direct meaning [10:23] get several revisions from repo [10:23] in a batch [10:24] igc: I've downloaded the docs about bzr-plugins from your lp +/junk address, did make html, got the result in _html directory (I think). Lots of complaints from Sphinx about missing parts. [10:24] I doubt it's treated as a list, because get_parent_map even deals with lists of revision keys. [10:24] igc: Do you expect the documenters to know Sphinx? Or how much you think we should attempt to learn Sphinx? [10:24] can't say off-hand [10:25] bialix: that patches looks good and I've just approved it [10:25] bialix: are you happy to land it? [10:25] igc: thanks [10:25] yes, I am [10:25] igc: should I write some special NEWS item? [10:26] OldAl: you need to know ReST. Sphinx adds a small amount over that [10:26] bialix: it's mostly internal isn't it? [10:26] bialix: add a NEWS item is there's an external impact [10:27] igc: yes, it's internal thing [10:27] igc: OK, I go to my home moinmoin (desktop version I use to keep records) and will change lots of pages to reST. I thought that moinmoin uses flat file system. Is that not so? [10:28] OldAl: flat file system? [10:28] moin supports it's own markup language and ReST [10:29] igc: moinmoin is plugable these days. We do use the flat file backend, but its not exposed on the web. [10:29] OldAl: ^ [10:29] igc: Most wikis are "flat file system"; They look structured, but internally they are flat file (all in one huge b. directory..). [10:29] igc: moinmoin may be smarter - have not looked in detail. [10:30] igc: Should be able to find out RSN, but thought you might know off hand. [10:34] lifeless: what does ^ mean in irc lango? [10:34] OldAl: that the line above also was addressed to you [10:36] lifeless: Oh, I see that - so my desktop moinmoin is probably flat file system, but not visible on launchpad version? [10:36] lifeless: It's ability of plugins is great for things like reST, listing of Python code, etc. [10:38] lifeless: My moinmoin desktop is kind of scratch pad. It is great for a guy with failing memory for record keeping... [10:52] lifeless: I get this message each time I connect: freenode-connect: Received CTCP 'VERSION' (to oldal) from freenode-connect. What does CTCP mean and what does the message say? [10:58] lifeless, ping [10:58] pong [10:59] lifeless: One of the sprint notes said you were working on uploading a bzr-rewrite package to Debian/Ubuntu [10:59] jelmer: its been uploaded to the bzr beta ppa I think [11:00] lifeless: Is that still true, any news in that regard? [11:00] I need to pull, audit and push to debian [11:00] packaging branch will be on lp:ubuntu/karmic/bzr-rewrite/* [11:00] lifeless: Ah, thanks [11:00] jelmer: if you want to do that, I won't say no :) [11:01] Maybe :-) I have some long-overdue sponsoring of qbzr and bzr-explorer packages to do first. [11:02] gnight [11:11] 'night [12:06] what is correct way to check if file actually ignored? [12:07] tree.is_ignored(path) does not check versionning info [12:07] so if the file in the tree is versioned but match ignored pattern? === mrevell is now known as mrevell-lunch [13:01] hi all, i have an existing project from when i first tried bzr and it contains a few revisions with a significant number of large binary files that aren't really related. in later revs i ignored them but they are still in the rev history and so checkout/branch take a LONG time and uses a lot of space. what is the best way (if its possible) to remove those files from the revision history? [13:07] night [13:14] ryanhaigh: rewriting the history makes new and old branches incompatible. if you're OK with this you can use either rebase (rewrite plugin) or fast-import-filter [13:15] hi GaryvdM [13:15] Hi bialix [13:16] thx for fast review [13:16] GaryvdM: do you have any ideas how to debug and fix Bug 487115? [13:17] Launchpad bug 487115 in qbzr "qcommit: (warning?) message in console when files grouped into directory" [Medium,Confirmed] https://launchpad.net/bugs/487115 [13:17] Pleasure. I thought that we behave the same as cli commit, but we were different. [13:17] bialix: re 487115 - Not sure off hand, but I will take a look [13:18] GaryvdM: actually it seems tree.is_ignored() is misleading API [13:19] I think this function should be named as is_match_ignore_pattern() [13:19] interesting, the patch with such change will be rejecting in first 15 min or so? [13:19] bialix: I've been working on https://code.launchpad.net/~garyvdm/qbzr/better_text_display [13:19] that's nice [13:20] GaryvdM: if you have any opinion on qshelve, I'd like to hear [13:20] (recent discussion with john szkameister) [13:21] bialix: Yes - the stuff that I'm working on is very related. I'm busy reading your mail carefully, and then I'm going to reply [13:21] I did not write my mail [13:21] actually I think we can and maybe should create line-based side-by-side editor for shelve [13:21] something like qannotate now [13:22] when every line easily identified [13:22] Yes - That is my plan [13:22] bialix: Your mail from this morning [13:23] yes, I did not finish it in morning -- have to run to work [13:23] Well - There is a mail in my inbox from you re qshelve. May be you sent if by mistake [13:23] *uit [13:23] *it [13:23] no, I've sent it debilerately [13:24] I've write second part tonight, about editor' [13:24] ok [13:24] *I'll write, sorry [13:25] GaryvdM: we have many good user-visible improvements in this release, I like it. Right for new year :-) [13:25] Thats cool [13:25] yeah [13:25] I've starting working on change of code layout [13:26] I hope to finish it and land after 0.17 === pickscrape_ is now known as pickscrape === mrevell-lunch is now known as mrevell [13:46] GaryvdM: I want to blog about new encoding selector in qbzr [13:47] I remember in the past you've published some of qbzr screenshots in main bzr blog? [13:47] Yes - poolie made me a author on there. Send Him a mail, and I'm sure he will do the same for you. [13:50] bialix: One of the things I want to do with qdiif, is make it possible to set the encoding per file. [13:51] GaryvdM: me too, did you saw the thread in bzr ML about versioned preperties? [13:51]