[06:08] <vila> hi all !
[06:09] <poolie> hi there vila
[06:10] <vila> poolie: _o/
[06:12]  * fullermd waves in some vague direction.
[06:28] <poolie> hi md
[06:55] <jam> morning all
[07:03] <vila> jam: _o/
[07:04] <vila> mgz: welcome on board !
[07:24] <fayaz> hi, is there a shortcut to remove the working tree from a branch?
[07:24] <lifeless> bzr remove-tree
[07:25] <fayaz> lifeless: thanks
[07:27] <fayaz> lifeless: what about for a shared repo?
[07:27] <lifeless> same
[07:49] <poolie> vila, so we agreed we're going to try to release lazr.restful, package it, etc?
[07:49] <poolie> if i don't get to it first you can
[07:52] <jam> poolie: weren't we going to do the 1:1 today?
[07:52] <poolie> yes, hi
[07:53] <poolie> was (unnecessarily) waiting for you
[07:54] <jam> poolie: ah, I said hi around 9, but you probably missed it
[07:54] <jam> I didn't see you talking, so didn't think you were around
[07:55] <poolie> shall we talk here or on the phone?
[07:55] <jam> poolie: either is fine by me
[07:56] <poolie> ok just busy here for a sec
[07:57] <jam> np
[07:57] <leo2007> I am getting this msg with the emacs repo. How to fix it? http://paste.pound-python.org/show/13019
[08:02] <poolie> leo2007, 'bzr tag --delete  mh-e-8.3' and   mh-e-doc-8.3
[08:02] <poolie> then pull again
[08:03] <leo2007> poolie: many thanks.
[08:05] <mgz> morning all.
[08:07] <leo2007> I am running Bazaar (bzr) 2.3.1. Is there sth I need to pay attention to when upgrading to 2.4.1
[08:08] <leo2007> some pages look like this on chrome http://imagebin.org/174112
[08:17] <poolie> leo2007, no, upgrading to 2.4.1 is safe
[08:17] <poolie> leo2007, that's interesting
[08:17] <poolie> i don't think it's connected to  bzr
[08:17] <poolie> are you in the middle of upgrading your os, perhaps?
[08:19] <poolie> mgz, hello!
[08:19] <mgz> hi poolie!
[08:20] <poolie> hi there
[08:20] <poolie> welcome
[08:20] <poolie> :)
[08:20] <jam> hey mgz! Good morning to you! And welcome to the gang :)
[08:23] <jam> leo2007: If you're upgrading the OS, I've seen some weird bits with rendering and certain Video drivers. It seems launchpad uses a very large image and then pulls sprites out of it. But its never hidden the text, just certain icons for me.
[08:23] <poolie> (all, mgz is joining Canonical starting today, there will be mail in a little bit)
[08:23] <poolie> mgz, when did you plan to typically start your day - around 9?
[08:24] <mgz> yes, planning to do that to start with then if it turns out to be better to do earlier or later will adjust.
[08:31] <leo2007> jam: no I am not upgrading os.
[08:32] <jam> leo2007: the only thing you upgraded was bzr and you started getting weird rendering in Chrome. Seems odd.
[08:32] <poolie> leo2007, suggest we ask in #launchpad
[08:34] <leo2007> no, no, I was browsing the bzr website and some of its pages load weirdly
[08:40] <vila> mgz: |0/
[08:40] <vila> oops \o/ I meant :)
[08:41] <leo2007> ok, now I am on 2.4.1 ;)
[08:46] <fullermd> vila: I should hope that's what you meant.  Otherwise, there's something wrong with your head...
[08:46] <vila> smoke going out mainly
[08:46] <mgz> okay, getting there...
[09:32] <poolie> hi mgz, flapping much?
[09:33] <mgz> just trying to work out what I'm going to do over email :)
[10:44] <jelmer> jam: You mentioned making a few updates to your 2.5-soft-hangup MP, but they don't appear to be on lp yet?
[10:45] <jam> jelmer: I did push, but not commit :)
[10:45] <jam> should be there now
[10:45] <jelmer> heh, thanks
[10:45]  * jelmer waits for the MP to update
[10:46] <jelmer> I'm looking forward to those longpoll changes to launchpad...
[11:00] <Riddell> if I have a string of a class's name, how can I instansiate the class?
[11:01] <jelmer> I guess something like eval(name)() assuming the class is properly imported, etc
[11:01] <jelmer> Riddell: why would you want to though? It's usually a bad idea
[11:01] <Riddell> jelmer: because your rewrite plugin lists the commands as strings in the info.py file :)
[11:02] <jelmer> Riddell: heh, ok
[11:02] <jelmer> Riddell: there is a method for looking up command classes by string
[11:03] <jelmer> Riddell: bzrlib.command.get_cmd_object
[11:04] <Riddell> jelmer: I don't think that'll work though if the plugin isn't installed
[11:04] <jelmer> Riddell: true
[11:04] <jelmer> Riddell: what are you trying to do exactly, what do you need?
[11:05] <Riddell> exporting the strings from rewrite plugin
[11:05] <jelmer> ... without having it installed ?
[11:05] <Riddell> I think expecting the plugin to be installed is too much of an assumption
[11:07] <jelmer> Riddell: why do you need to look up classes though?
[11:07] <Riddell> I need to instansiate the class to pass it to bzrlib.export_pot._write_command_help
[11:08] <jelmer> Riddell: if you need to instantiate anything, that requires loading the plugin
[11:09] <jelmer> Riddell: that doesn't seem too bad though, it's always possible to use the BZR_PLUGINS_AT env variable
[11:09] <Riddell> it works fine to just run  cmd_rebase()
[11:12] <jelmer> Riddell: that's not guaranteed for any of the other plugins though, which may rely on other code in __init__.py having run
[11:15] <jelmer> Riddell: it's odd that just cmd_rebase() would work - did you import anything else, do you have bzr-rewrite installed perhaps?
[11:16] <Riddell> jelmer: this is what I have http://paste.kde.org/127417/
[11:17] <jelmer> Riddell: that's only going to work if you have the plugin installed
[11:18] <jelmer> Riddell: it also assumes that the commands are living in commands.py, which isn't necessarily true
[11:18] <mgz> okay, I've sent a hello message to the mailing list
[11:18] <Riddell> jelmer: I don't  have rewrite installed (according to `bzr plugins`
[11:18] <mgz> if someone is free later to try testing out voip things with me, that would be really handy
[11:18] <Riddell> jelmer: well this is specific to bzr-rewrite, other plugins would have to adapt
[11:18] <Riddell> mgz: ah, you're on a new mailing list, that's exiting :)
[11:19] <Riddell> mgz: I've never done voip, how are you setting it up?
[11:20] <mgz> on this machine if at all possible, otherwise I'll just use my phone
[11:20] <jelmer> mgz: hello!
[11:21] <mgz> jelmer: hi, nice to meet you!
[11:21] <jelmer> Riddell: I'd personally prefer something more generic, even if that somehow requires loading the plugin
[11:22] <jelmer> Riddell: importing info and commands is going to load some bits of the plugin anyway, so I don't really see how what it gains us
[11:22] <jelmer> mgz: :)
[11:23] <Riddell> jelmer: well this way e.g. packagers can run make update-pot and know it'll work, if you have to have the plugin installed it might pick up the wrong version of the plugin or not work at all
[11:24] <jelmer> Riddell: This is much more likely to regress because importing commands might require on side-effects from __init__
[11:24] <jelmer> riddell: there are ways to load plugins from specific locations
[11:25] <jelmer> vila: ^
[11:25] <vila> BZR_PLUGINS_AT ?
[11:25] <Riddell> mgz: doesn't a voip account require asking sysadmin for one, or are you not using canonical's server?
[11:26] <jelmer> Riddell: I got my VOIP credentials by email automatically on my first day?
[11:26] <fullermd> It's a rite of passage.  You're supposed to hack into the server and set yourself up...
[11:27] <vila> jelmer: Not sure I understand the question :-}
[11:28] <jam> jelmer: if there is anything I can do to make it easier to review my changes, just ask. I'm happy to discuss them line-by-line, etc.
[11:28] <jelmer> jam: I'm having another look at them now
[11:29] <jam> mgz: I've got voip set up if you want to test it, or mumble, or whatever
[11:31] <Riddell> vila: I need objects of cmd_rebase etc from the rewrite plugin so I can pass them to export_pot._write_command_help() and get the translations
[11:31] <vila> Riddell: about your pasted snippet, beware that '-' is translated to '_' between the command name and command class name, get_command_object which should take care of that
[11:32] <Riddell> it seems to work fine if I just do  foo = cmd_rebase()  but that might not be reliable for all commands
[11:35] <vila> not all plugins use the info.py trick and the ones who do don't necessarily declare bzr_commands :)
[11:35] <jelmer> .. and not all of them have their commands living in commands.py
[11:35] <vila> yeah, so, bzrlib.commands.plugin_cmds may be a better source
[11:42] <Riddell> mm
[12:04] <jelmer> jam: I'm getting an additional leaked thread from bb.test_serve with your MP
[12:05] <jam> jelmer: I don't....
[12:05] <jam> but let me check another machine
[12:05] <jelmer> jam: aren't you missing a call to finish_bzr_subprocess?
[12:05] <jam> jelmer: could be
[12:06] <jelmer> that fixes it for me, fwiw
[12:06] <jelmer> http://pastebin.ubuntu.com/697224/
[12:07] <jam> jelmer: I'm calling "assertFinishesCleanly" right?
[12:07] <jelmer> jam: nope
[12:07] <jam> hmm, I was
[12:08] <jelmer> jam: IIRC assertFinishesCleanly tries to send a SIGINT
[12:08] <jam> jelmer: so add assertFinshesCleanly
[12:08] <jam> after the readline
[12:08] <jam> for the test involved either is fine.
[12:08] <jam> All I'm testing is that you *can* connect, and that SIGHUP triggers the shutdown code.
[12:08] <jelmer> jam: assertFinishesCleanly doesn't work:
[12:09] <jelmer> a = 'bzr: interrupted\n'
[12:09] <jelmer> b = 'Waiting for 1 client(s) to finish\nbzr: interrupted\n'
[12:09] <jam> If we want, I can extend that code and make sure it doesn't actually stop
[12:09] <jelmer> finish_bzr_subprocess seems fine though
[12:09] <jelmer> since it doesn't check stdout
[12:09] <jam> jelmer: and, TBH, that "waiting for 1 client" is going to be random, depending on timeouts, etc.
[12:09] <jam> jelmer: let me poke at that one, I actually want to do something like the 1MB tests I was doing elsewhere.
[12:10] <jelmer> here's another one I hit: http://pastebin.ubuntu.com/697229/
[12:10] <jam> we could certainly leave the test to only make sure that "Requested to stop gracefully" and assume that means everything is hooked up
[12:10] <jam> jelmer: thx, I've been doing mixed windows and Linux testing. And I changed that line from 'signal.signal.' to signal.getsignal
[12:11] <jam> but didn't notice because it doesn't run on Windows.
[12:11] <jam> jelmer: so... What do you think about having a test that writes 1MB to disk? It seems a bit ugly. I want it to be larger than the socket buffer, though.
[12:13] <jelmer> jam: is it really writing 1MB to disk? from my reading of the test it seemed like it put 1Mb on a memorytransport
[12:13] <jam> jelmer: that was the other tests. I'm thinking to adapt the 'bb.test_serve' test to do something similar
[12:13] <jam> 64kB is probably enough
[12:14] <jam> (waits for fuller-md to notice :)
[12:15] <fullermd> It's not a real test unless it's a prime number.
[12:23] <jelmer> jam: It seems pretty well tested at this point, what's the reason you're thinking of having the bb.test_serve test do something similasr?
[12:23] <jelmer> *similar
[12:23] <jam> jelmer: acceptance test
[12:23] <jam> since it is a 'blackbox' test.
[12:23] <jelmer> hmm
[12:24] <jelmer> is there a portable way to set the socket buffer size/
[12:24] <jelmer> ?
[12:26] <jelmer> jam: if there's no other way to test it, then it doesn't seem too unreasonable. Of course, we shouldn't be doing stuff like this in too many tests..
[12:26] <jam> jelmer: there is setsockopt(SO_SNDBUF)
[12:26] <jam> Though I'm pretty sure 64kB is sufficient, 1MB I would think is quite big
[12:27] <jam> jelmer: the test passes on devpad at 64kB
[12:27] <jam> jelmer: if I did it correctly, there is only ~1 new acceptance test is bb.test_server
[12:27] <jam> I agree that we shouldn't do them for most testing
[12:28] <jelmer> jam: that seems perfectly fine to me, fwiw
[12:30] <jam> jelmer: updated test pushed
[12:30] <jam> and the fix for signal.getsignal
[12:30] <jam> well, pushed now. (had to put in ssh key:)
[12:30] <jam> r6021
[12:30] <jam> r6201
[12:36] <jelmer> jam: lo
[12:36] <jelmer> jam: sorryu
[12:37] <jelmer> argh, my keyboard is acting up
[12:37] <jelmer> jam: Anyway, I was going to say that it all looks reasonable to me. The large number of tests is really nice, and actually helped me understand how things are working.
[12:40] <jam> jelmer: yeah, it helped me to assemble it as well :)
[12:40] <jam> There were a couple of races in the code (racing against the test suite), but I was able to think them through, and make sure things were changed
[12:40] <jam> so that there was always communication between the time variables were inspected.
[12:41] <jam> (make sure to add the item to the list before you talk on the socket, etc.)
[12:42] <jelmer> jam: yeah, it seems particularly hard to consider all the corner cases here
[13:04] <jelmer> jam: was somebody else still looking at your other in-progress MP?
[13:04] <mgz> okay, had lunch, and am on mumble server
[13:04] <mgz> ...I probably need a better mic though
[13:05] <mgz> can someone spare a moment to come on and tell me how much too quiet I am?
[13:08] <jam> jelmer: poolie approved it offline
[13:08] <jelmer> jam: cool
[13:11]  * jelmer stumbles onto mumble for a bit too
[13:18] <jelmer> working mumble in under 5 minutes!
[13:18]  * jelmer sees progress
[13:42] <mgz> cool, mumble experiment worked
[13:43] <mcepl_> could somebody suggest 100% working way how to get working bzr fast-export on Fedora?
[13:43] <mcepl_> I have to do symlinking of fastimport to ~/.local/lib/python27/site-modules and yes I get this backtrace http://fpaste.org/RFaK/
[13:47] <jelmer> mcepl_: do you perhaps also have fastimport in ~/.bazaar/plugins with a different name?
[13:47] <mcepl_> jelmer: well, I have ... when I don't how is bzr supposed to find it?
[13:48] <mcepl_> I am sorry, i am not very good with bzr (use fast-export only to get the repository to git so i don't have to bother with bzr anymore ;))
[13:48] <jelmer> mcepl_: bzr will either find it in the standard Python import path at bzrlib.plugins.fastimport
[13:49] <jelmer> or you can add the plugin in ~/.bazaar/plugins, e.g. "bzr branch lp:bzr-fastimport ~/.bazaar/plugins/fastimport"
[13:49] <mcepl_> when I tried to follow http://doc.bazaar.canonical.com/plugins/en/plugin-installation.html
[13:49] <mcepl_> which doesn't work
[13:49] <mcepl_> let me give you the error message
[13:51] <mcepl_> jelmer: http://fpaste.org/PHVY/
[13:51] <mcepl_> what am I missing?
[13:53] <jelmer> mcepl_: can you pastebin the output of "bzr plugins -v" ?
[13:54] <mcepl_> no problems there http://fpaste.org/ZmiO/
[13:56] <jelmer> hmm
[13:56] <jelmer> mcepl_: did you try to install fastimport any other way perhaps, are there other copies elsewhere on your system?
[13:57] <jelmer> it seems that somehow "from fastimport import ..." is loading the bzr plugin rather than the fastimport python module
[13:58] <mcepl_> I don't think so http://fpaste.org/LiCQ/
[13:58] <jelmer> mcepl: /home/matej/.local/lib/python2.7/site-packages/fastimport
[13:58] <jelmer> mcepl_: what's that?
[13:58] <mcepl_> locate fastimport from whole system
[13:59] <mcepl_> proof, that there is no other copy of fastimport here
[13:59] <jelmer> mcepl_: what kind of link is it?
[13:59] <mcepl_> oh, that's a dead symlink to
[13:59] <mcepl_> when i remove that I get
[13:59] <mcepl_> mitmanek:~ $ bzr selftest fastimport
[13:59] <mcepl_> bzr: ERROR: No module named fastimport
[13:59] <mcepl_> You may need to install this Python library separately.
[13:59] <mcepl_> mitmanek:~ $
[14:00] <jelmer> mcepl_: You need to install the python fastimport module (which is different from the bzr fastimport plugin)
[14:00] <mcepl_> doh
[14:00] <mcepl_> where does it grow?
[14:01] <jelmer> it's in the cheeseshop, or http://launchpad.net/python-fastimport
[14:02] <mcepl_> I don't think we have it in Fedora
[14:02] <jelmer> (or packaged in Debian/Ubuntu/Arch/Fink/..., but I guess you're on RH ?)
[14:02] <jelmer> yeah
[14:03] <mcepl_> OK, got it
[14:04] <mcepl_> I accept that this is PEBKAC, but I think there could be something more explicit at somewhere.
[14:04] <mcepl_> now I have succesful selftest
[14:05] <jelmer> mcepl_: yeah, it's a bit unfortunate. the bzr-fastimport commands ("bzr fast-import", etc) give a clearer message but not selftest
[14:13] <mcepl_> jelmer: any ideas about http://fpaste.org/91vw/ ... (it's bitlbee repo BTW)
[14:14] <mcepl_> bzr: ERROR: 86daca7b9076381129708faf127820de.iix is not an index of type <class 'bzrlib.btree_index.BTreeGraphIndex'>.
[14:16] <mcepl_> bazaar 2.4.0, git 1.7.6.2
[14:18] <jelmer> "charis:/tmp/bitlbee.git% bzr fast-export --plain http://code.bitlbee.org/bitlbee | git fast-import" seems to work fine here
[14:18] <mcepl_> I'll try once more from plain directory
[14:20] <mcepl_> no error, but
[14:20] <mcepl_> 16:20:12 WARNING: not creating tag u'1.2.7-1' pointing to non-existent revision wilmer@gaast.net-20100515151824-1bv2apjub0w9c66j
[14:21] <jelmer> mcepl_: right, git doesn't support ghosts
[15:27] <mgz> jam: is there extra overhead for a 'def' function in pyrex than a 'cdef' one? I forget.
[15:28] <jam> mgz: a 'def' function is a regular python func, accessible to other python code
[15:28] <jam> cdef is a pure C func, not accessible from general python code
[15:29] <mgz> right, and if I want to expose a (currrently) cdef function, should I wrap it in a new def one, or just change it to def?
[15:29] <mgz> I'm looking at dirstate.pack_stat
[15:29] <jam> mgz: 'it depends' :) If it is critical time, you want a wrapper
[15:29] <mgz> (...which I also have problems benchmarking... the best I've come up with is a big tree and touching every file)
[15:30] <mgz> okay, a wrapper is what I have, will commit
[15:30] <jam> mgz: you shouldn't have to touch every file, a big tree should be enough
[15:30] <jam> specifically, pack_stat gets called for each one to compare it to the stored value
[15:32] <mgz> ah right, but I can't then see it in the profile because the pyrex version is called directly from another pyrex function
[16:06] <exarkun> bzr error, <http://buildbot.twistedmatrix.com/builders/winxp32-py2.7/builds/440/steps/bzr/logs/stdio>, "Cannot create a file when that file already exists"
[16:12] <mgz> hm, can you make your bot use -Derror exarkun?
[16:13] <exarkun> 'bzr -Derror checkout ...'?  Probably not.
[16:16] <mgz> could set it in bazaar.conf instead?
[16:18] <mgz> if you could find that error in .bzr.log that would do too.
[16:19] <exarkun> I can probably find it in .bzr.log
[16:20] <exarkun> er, if I can find the directory that file is in.
[16:24] <exarkun> ah, there it is.  I wonder how to get it off this computer.
[16:35] <mgz> ...I hope you're not typing it across by hand :)
[16:41] <vila> ... he needs to learn it by heart before he starts typing
[16:43] <mgz> okay, end of day 1 aim, fix two bugs with seven duplicates between them.
[16:46] <vila> mgz: way to go ! Congrats !
[16:47] <mgz> first, to write some tests...
[17:09] <Noldorin> hi jelmer
[17:09] <jelmer> hi Noldorin
[17:10] <Noldorin> how's it going?
[17:10] <Noldorin> any much progress? :-)
[20:52] <SpamapS> Is there a way to force a 'bzr export lp:something' to not use ssh ?
[20:58] <mwhudson> SpamapS: BZR_HOME=/tmp bzr export ... probably works, for slightly obscure reasons
[20:58] <mwhudson> SpamapS: why do you want to avoid ssh?
[20:58] <mwhudson> jelmer: i assume you've seen https://code.launchpad.net/~python-dev/python/trunk and related fun?
[21:00] <SpamapS> mwhudson: automated test
[21:00] <SpamapS> mwhudson: in a chroot, so it won't have access to my SSH keys
[21:00] <mwhudson> ah ok
[21:01] <SpamapS> actually thats perfect that solves some of my other problems.
[21:01] <mwhudson> SpamapS: don't set launchpad-login in the chroot?
[21:01] <SpamapS> I don't
[21:01] <SpamapS> $HOME is bind mounted..
[21:01] <SpamapS> so its picking up anything in there
[21:01] <mwhudson> oh
[21:01] <mwhudson> right
[21:01] <SpamapS> exporting that at key moments to /tmp/sometmpdir will work actually
[21:01] <mwhudson> then BZR_HOME=/random/stuff
[21:02] <mwhudson> is probably reasonably appropriate
[21:02] <mwhudson> (or running as a different user in the chroot, or something)
[21:20] <jelmer> mwhudson: yep, working on submitting an updated bzr-svn
[21:27] <Kilroo> This is relevant to my interests.
[21:28] <Kilroo> Hehe. I was actually just revisiting bzr today for purposes of comparing bzr-svn and hgsubversion.
[21:29] <jelmer> Kilroo: this issue has already been fixed in bzr-svn, it's just because of the snapshot of bzr-svn launchpad is using
[21:30] <Kilroo> I don't know what issue you mean; I just happened to get home from work and look in here and see you talking about it. I was entertained.
[21:30] <jelmer> ah, ok :)
[21:31] <Kilroo> I think I figured out the shortest sequence of steps to combine bzr-svn and bzr-colo to result in the closest possible analog to what hgsubversion does by default with a TBT svn-layout.
[21:33] <jelmer> I'm not sure what hgsubversion does by default - what did you end up with?
[21:34] <Kilroo> Ah...well, what I actually tested was...I think... bzr colo-init; bzr svn-import <source> .bzr/branches/origin; bzr switch colo:origin/trunk; bzr colo-prune colo:trunk
[21:35] <Kilroo> I'm actually curious whether bzr init-repo --no-trees; bzr svn-import <source> .bzr/branches/origin; bzr checkout --lightweight colo:origin/trunk would accomplish effectively the same thing.
[21:36] <jelmer> you'd definitely need colo-init somewhere in there if you want to use bzr-colo
[21:37] <Kilroo> ok. That was the part I wasn't sure about, because one of the things I was looking at seemed to imply that switch colo:etcetera would work without it.
[21:38] <Kilroo> Incidentally, If you have hgsubversion and you hg clone the root of a trunk-based svn repository it just translates it into Mercurial named branches.
[21:39] <jelmer> Kilroo: we're making colocated branches a part of core bazaar, so in the future just "bzr clone <svn-url>" would do the same thing
[21:39] <Kilroo> Yeah, I was reading up on that.
[21:40] <jelmer> mwhudson: still there?
[21:40] <mwhudson> jelmer: hi
[21:42] <jelmer> mwhudson: can I trouble you for a quick lp review? It's the update of bzr-svn to fix the tags issue
[21:42] <mwhudson> jelmer: sure
[22:02] <mozmck> I'm using tortise bzr in windows.  Can I revert to a previous revision of my code but still keep the changes I'm reverting away from?
[22:03] <ccxCZ> you probably want uncommit then, not revert
[22:05] <mozmck> Will this keep my changes in the repository?
[22:05] <mozmck> The revision I want is 3 revs back.
[22:07] <ccxCZ> if you want to diff to that revision you can just do that. if you want to create separate working tree on that revision, you can checkout that specific revision
[22:07] <ccxCZ> not sure what you are trying to do
[22:08] <mozmck> I guess checking out the specific revsion in another tree will work.
[22:09] <mozmck> I am trying to go back to some code I had working, but keep my other changes in case I need them later.  A separate tree is probably the best way.
[22:09] <ccxCZ> probably. you can also shelve your changes
[22:11] <mozmck> Ah, hadn't seen that command before.  Thanks!
[23:09] <poolie> mozmck, ccxCZ, if you want to keep uncommitted changes use shelve
[23:09] <poolie> if you want to leave the committed changes alone but go back to a previous revision, use update
[23:21] <mwhudson> jelmer: i guess you didn't need me for that review after all?
[23:21] <jelmer> mwhudson: sorry, I forgot to mention
[23:22] <jelmer> mwhudson: my kernel oopsed and when I rebooted Curtis had already done a review
[23:22] <mwhudson> jelmer: hahaha
[23:22] <jelmer> mwhudson: thanks, though
[23:22] <mwhudson> don't worry, i haven't been hanging around waiting
[23:23] <jelmer> mwhudson: heh
[23:23] <jelmer> mwhudson: thanks for *offering* to review that branch :P