[01:07] <GungaDin> when I'm trying to checkout a branch on Windows, I get "exceptions.NameError: global name 'readline' is not defined... any ideas?
[03:55] <AfC> Has locking been removed to the point where Bazaar is safe over NFS now?
[04:58] <mwhudson> AfC: i don't think working trees on nfs are a particularly good idea yet
[04:59] <mwhudson> (not sure though!)
[04:59] <AfC> mwhudson: [yeah, I've been searching docs and not finding advice either way]
[04:59] <AfC> I was vaguely mostly wondering about branches & repositories.
[05:00] <mwhudson> i think that ought to be ok
[05:08] <AfC> hm
[05:11] <AfC> Branches on a file:/// at a NFS mount, or bzr+ssh:///
[05:16] <lifeless> bzr+ssh
[05:16] <lifeless> nfs will work its just a bad idea
[05:23] <AfC> lifeless: fair enough
[05:23] <AfC> thanks
[05:23] <AfC> [my suspicion was that revisions locally is better than asking NFS to ship them around and being blocked on network to get them into host cache]
[05:25] <lifeless> think of it like 'is running sqlite, or access, or postgresql, on nfs a good idea'
[05:25] <lifeless> bbiab
[07:38] <vila> hi all !
[08:04] <poolie> hi vila
[08:04] <poolie> vila, can you be pp this week?
[08:10] <vila> that was quick :)
[08:11] <vila> poolie: yes, until thursday
[09:09] <poolie> hi vila
[09:09] <vila> poolie: hey !
[09:09] <poolie> thanks for the reviews!
[09:10] <vila> poolie: more to come ;)
[09:10] <poolie> you're ok to pilot?
[09:10] <poolie> thanks, i was slack at it last week
[09:10] <poolie> i think i had a good excuse
[09:10] <vila> poolie: sure, I'm already doing it, just wanting to remind you that I'll stop Thursday
[09:11] <poolie> np
[09:12] <vila> jelmer: welcome back !
[09:12] <jelmer> 'morning vila
[09:12] <poolie> hi jelmer
[09:13] <jelmer> vila: thanks :-)
[09:13] <jelmer> hi Martin
[09:13] <poolie> wish you'd been here, it was a great sprint
[09:13] <jelmer> I bet, I wish I could've made it too :-(
[09:15] <vila> jelmer: feel free to ping me about https://code.edge.launchpad.net/~vila/bzr-svn/525571-minimal-atomic-write-bazaar-conf-files-2.1/+merge/29439 when you want, your fix on bzr-svn trunk is based on a fix that will not land on bzr trunk for a little while so you may have to tweak a bit
[09:18] <james_w> hi vila, hi jelmer
[09:18] <vila> hey james_w
[09:19] <jelmer> hi James
[09:19] <jelmer> vila: I'll have a look this evening - thanks
[09:49] <poolie> jam so the followon i https://code.edge.launchpad.net/~mbp/bzr/32669-2.0-symlink-branch/+merge/30241
[09:49] <poolie> apparently not passing yte
[10:26] <poolie> vila, i was just talking to jam about fixing bugs in 2.0
[10:27] <jam> hi vila
[10:27] <vila> hi ajm
[10:27] <vila> meh, hi jam
[10:28] <poolie> and the agreement, which is not super surprising, is that we should merge things that are either small fixes and at least a medium bug, or a critical bug with the smallest sufficient fix
[10:29] <vila> right, so your last symlink fix is ok or not ?
[10:29] <poolie> so these things for symlinks are probably only for trunk
[10:29] <vila> the add SYMLINK/FILE that is
[10:29] <vila> ha, good, I feel better this way too
[10:29] <poolie> good :)
[10:30] <vila> not that the fixes sound risky, but changing the behaviour there... has its own risks
[10:31] <poolie> right
[10:34] <poolie> these dependent branch things are not as good as they could be
[10:49]  * vila breathes again, running the full test suite in 3 hours was a pain :-(
[11:00] <fullermd> Long time to hold your breath, too   :p
[11:01] <vila> fullermd: only a week working my underpowered laptop, good practice for scuba diving :p
[11:04] <vila> wow scuba *is* an acronym...
[11:04] <fullermd> Everything's an acronym if you get creative enough  ;>
[11:05] <vila> fullermd: how about superfragilisticexpialidocious
[11:05]  * vila won't hold his breath there :-D
[11:10] <fullermd> Sustained Underwater Peristalsis through Extremely Ribald Falsetto Ringtones And Gyrating Intersteller Longranger Interferometric Seismic Tortoise Interloping Calling Enough Xylophonic Porpoises for Inter-Alia Licorice In Destructive Obsequious Cacophanies Intersperced with Obviously Ultimate Sequins
[11:11]  * fullermd gasps for breath.
[11:11]  * vila googles acronymizer
[11:11] <fullermd> That would be cheating.
[11:12] <vila> right, google didn't find yours...
[11:12] <vila> ...yet
[11:12] <vila> :)
[12:47] <Glenjamin> hi guys, i'm trying to set up a basic authenticating server using ssh
[12:48] <Glenjamin> so far i've got a ssh shell wrapper that forces a directory, but i can only see to capture the bzr serve call, there's no information about which branch is being requested
[12:48] <Glenjamin> so my question is - can I check which branch is being accessed somehow?
[12:49] <Glenjamin> my script so far is pretty much http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head:/contrib/bzr_ssh_path_limiter
[12:57] <mandel> quick question here to see if I understand correctly, if a do "bzr add dir/" all the contents of the dir should be added, am I right?
[12:57] <Glenjamin> except those that match ignore patterns, yes
[12:59] <mandel> Glenjamin, which are present in .bzrignore, right?
[12:59] <mandel> Glenjamin, can they be found somewhere else?
[13:02] <mandel> I'm working on windows and wanted to add a folder with a subfolder with  binnaries to a branch and all the binnaries have been ignored from the nested folder , and I was wondering if that was a feature
[14:14] <Glenjamin> does anyone know roughly where in the code the bzr client runs the SSH command to start up the server for the bzr+ssh:// transport?
[14:14] <Glenjamin> i'm trying to add in an environment variable to provide details of what the server connection is for.
[14:17] <LeoNerd> Doesn't it use paramiko these days, and hence doesn't -actually- run /usr/bin/ssh at all..?
[14:17] <Glenjamin> not a clue, all i know is the server receives bzr serve --directory=/
[14:17] <Glenjamin> and i'd like to try and pass more information there
[14:18] <vila> Glenjamin: bzrlib.transport.ssh ?
[14:22] <mgz> ...the easiest way to add an envvar is just to add it to the environment you're running bzr in, not fiddle with the ssh code
[14:23] <mgz> they get passed along to child processes
[14:24] <mgz> I see jam's done the review on the ~nmb branch I collapsed before posting last night, so that's one less job
[14:25] <mgz> there's one other existing error class that defines a similar __str__ method and should probably be changed as well
[14:27] <Glenjamin> mgz: would that add the env var to the remote ssh connection?
[14:27] <cr3> is there a way to get a log between given timestamps?
[14:28] <Glenjamin> i want to send the command line bzr was given to the ssh wrapper that accepts the connection - for permission checking
[14:29] <mgz> ah, I hadn't read closely enough. easiest to fiddle with the default environment of the remote user, then?
[14:33] <Glenjamin> if i do "bzr push bzr@bzr.server.com/project/branch" i'd like to set BZR_COMMAND=push and BZR_PATH=/project/branch on the initial SSH connection.
[14:33] <Glenjamin> or something along those lines
[14:34] <mgz> oh, so you don't really need a different env, you just want to look at the logging
[14:34] <mgz> see .bzr/log on the server, it will have all that and more
[14:34] <Glenjamin> oh
[14:35] <Glenjamin> interessant
[14:35] <mgz> $BZR_HOME/.bzr.log
[14:36] <Glenjamin> surely the command string is in the _client's_ bzr log?
[14:37] <mgz> depends what you mean by command
[14:37] <mgz> what you type on the terminal is in the client's log
[14:37] <mgz> what smart operations actually run are in both.
[14:38] <Glenjamin> yeah, this is part of the problem - i'm using a script like http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head:/contrib/bzr_ssh_path_limiter
[14:38] <Glenjamin> the ssh shell thing just gets the bzr serve command, and then the actual command is sent through a different medium
[14:39] <Glenjamin> there's a program called bazitis, which does the remote permissions by replacing the file:// handler. I was trying to something simpler
[14:41] <mgz> okay, reading further back in the log I now understand even less
[14:43] <Glenjamin> yeah, i'm not convinced i'm being entirely clear, i'll go back to the problem - not my perceived solution
[14:43] <mgz> you're trying to do a more complicated authentication scheme than just user permissions?
[14:43] <Glenjamin> sort of
[14:43] <Glenjamin> i'm doing it like gitosis, where you have a single user, and each key auth uses a different shell
[14:44] <Glenjamin> which is a program that does a check against SSH_ORIGINAL_COMMAND
[14:44] <Glenjamin> the whole repo is owned by the "bzr" user, and auth is handled separately
[14:45] <Glenjamin> this work fine in git, because the command sent contains the full path - but doesn't in bazaar because of the way the smart protocol works
[14:46] <Glenjamin> the reason for doing it this way, is to avoid giving everyone full ssh accounts
[14:47] <Glenjamin> and to enforce the repos all being in the same place
[14:49] <cr3> using bzrlib, how can I get a branch object from a path already created as a branch?
[14:50] <Glenjamin> cr3: http://doc.bazaar.canonical.com/bzr.2.1/developers/integration.html should be what you need
[14:50] <mgz> okay. trying to work this with bzr+ssh seems perverse to me, but copying what some git thing does explains why at least.
[14:50] <cr3> Glenjamin: awesome, thanks!
[14:51] <vila> Glenjamin: keep in mind though that, unlike git, the repository may not be at the same place that the branch
[14:52] <Glenjamin> my intention was to force everything through this same script, so I can enforce things like central repository layout
[14:56] <Glenjamin> so, given that this has probably been the wrong way to approach this
[14:57] <Glenjamin> what's the recommended way to handle a central repository with user-based permissions in a corporate environment?
[14:59] <vila> Glenjamin: using bzr+http may be a bit more setup for the server itself, but then, it provides many solutions to define/authenticate the users
[14:59] <vila> Glenjamin: from there defining specific .htmlaccess files becomes the easiest I think
[15:01] <vila> Glenjamin: but there is also contrib/bzr_access which AIUI does what you want
[15:03] <Glenjamin> bzr access only supports global permissions, since it wraps the initial ssh connection - which has no knowledge (nor really cares) what it's being opened for :(
[15:05] <vila> Glenjamin: but you can still use different keys, i.e. one by project if really needed
[15:05] <vila> Glenjamin: how many projects are you trying to handle or how many teams if they work on the same projects ?
[15:12] <Glenjamin> vila: to begin with, it's just going to be one project with maybe 5 devs, but i hate the git setup we have atm, so ideally i'd want to replace our gitosis setup with this
[15:13] <vila> Glenjamin: for a given project, it makes sense to define groups for read and write operations for all the branches in the repository, what feature is missing for you ?
[15:15] <Glenjamin> i was hoping to manage multiple projects using a single key for each user
[15:16] <vila> Glenjamin: bzr_acess finds its config file in the repository, so you can specify different access rights for a given user at this level
[15:17] <vila> bah, I meant, for the same user, each repo defines the access rights, that gives you rights by project
[15:18] <Glenjamin> but bzr serve always receives --directory=/
[15:18] <Glenjamin> and then the protocol itself requests the full path
[15:19] <vila> Glenjamin: but it will receive --allows-write or not and will not be called if the permission is denied, at least that's how I read the script...
[15:19] <vila> Glenjamin:
[15:24] <Glenjamin> my understanding is that each line in the authorized_keys file has to match a unique key, and the command string on that line is the only place you can tell bzr_access which repo to look at
[15:25] <vila> doh
[15:26] <Glenjamin> i sorta want to be able to hook into the SmartClientMedium
[15:26] <Glenjamin> but there's no entry point
[15:27] <vila> Glenjamin: indeed, hmm, the next simplest thing would be define a user by project on the server :-/
[15:28] <vila> Glenjamin: I think you should talk with spiv then, he should be able to give you the most detailed answer
[15:29] <vila> Glenjamin: I think he's travelling right now but he should resume his online presence in AU tz soon
[16:07] <Glenjamin> i've come up with a silly hack that involves hooking into http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head:/bzrlib/smart/request.py#L171 :D
[16:17] <jam> vila: poke
[16:17] <jam> looking into the python2.7 compatibility issues
[16:17] <vila> jam: :)
[16:17] <jam> it looks like the problem is in how we are poking at xmlrpclib so that it can support proxies
[16:18] <jam> it seems that xmlrpclib wants an httplib.Response object, and we are giving it a _urllib2_wrappers.Request object
[16:19] <jam> the main difference from what I can see
[16:19] <jam> one has 'def getheaders'
[16:19] <jam> the other has
[16:20] <jam> 'def get_header'
[16:20] <jam> (sorry, both are singular)
[16:20] <jam> the difference is in the underscore
[16:20] <vila> jam: from the top of my head, can't they both use .headers instead ?
[16:20] <jam> vila: I can't change the stdlib
[16:20] <jam> unless you *really* want to hack stuff
[16:20] <jam> look at http://docs.python.org/dev/whatsnew/2.7.html
[16:20] <jam> it mentions that xmlrpclib now supports keep-alive, etc
[16:20] <jam> which means it checks headers
[16:21] <jam> which means it breaks vs our work-around for proxies
[16:21] <vila> jam: what seems suprising is that one gets a response when the other get a request...
[16:21] <jam> vila: yep
[16:22] <jam> vila: I may not have followed the traces enough yet
[16:23] <jam> the bug mentions this fails: if response.getheader("Content-Encoding", "") ==  "gzip":
[16:23] <vila> urgh, who is playing with content-encoding ?
[16:23] <vila> jam: bug $ again ?
[16:23] <vila> jam: bug # again ?
[16:24] <jam> vila: bug #605574
[16:24] <vila> thks
[16:25] <vila> ha right, urgh, addinfourl is an ugly hack...
[16:26] <jam> vila: sure, but I think it is masking the real thing
[16:27] <jam> vila: specifically, python2.6.5 doesn't ever call getheader
[16:27] <jam> python2.7 does
[16:27] <vila> jam: sure
[16:27] <vila> so, are you reproducing that right now ?
[16:27] <jam> both to check the "Content-Length" header, and to check "Content-Encoding"
[16:27] <jam> vila: yeah, no problem reproducing
[16:28] <jam> vila: /usr/local/bin/python2.7 bzr info lp:bzr
[16:28] <jam> fails in the xmlrpc lookup of 'lp:bzr'
[16:29] <vila> oh,, cool, let me try that
[16:29] <poolie> jam, can you find michael hope and talk about release process, if you're not busy?
[16:30] <vila> meh, no py27 for lucid ? :-/
[16:30] <poolie> vila there's a ppa i think
[16:30] <jam> vila: nope
[16:30] <poolie> maybe that's only maverick
[16:30] <jam> poolie: barry is sort of looking at it
[16:30] <vila> poolie: will check
[16:31] <jam> but doko only built for maverick
[16:31] <jam> poolie: I don't know who that is, but otherwise I would be willing
[16:31] <vila> ha, time for new babune slave then :->
[16:31] <jam> vila: yeah, I built from source to test this
[16:32] <vila> jam: hmm, so for a short answer: if get_header or getheader should be added to _urllib2_wrappers class this shouldn't to hard, I more or less remember getting away from addinfourl objects though so I'm a bit surprised to see one in the traceback
[16:33] <vila> may be I just wrap it very late and I never put the headers there since they were not needed
[16:34] <vila> jam: but for context: why are you looking at this ? I didn't thought 2.7 was urgent, is there a chicken-and-egg problem for someone here ?
[16:35] <jam> vila: maverick would like to include 2.7 as an installable package
[16:35] <jam> it can't unless they can build all python packages for both 2.6 and 2.7
[16:35] <jam> also
[16:35] <jam> 2.7 is out
[16:35] <jam> it would be good to be compatible with it
[16:35] <jam> and barry is here to work with :)
[16:37] <vila> jam: ok, makes sense, say sorry and hi to Barry from me then :)
[16:37] <jam> vila: barry says hi, and enjoy your evening
[16:38] <jam> vila: first thing when trying to use the original transport... itgets a 302 redirected error and basically just dies ... :)
[16:38] <vila> ..and fallback to a bzr one ?
[16:39] <jam> vila: I hacked out the XMLRPCTransport code so that I could try to figure out what object it is actually getting
[16:41] <vila> wow, qblame confirms I wrote this class, it looks weird, this smells like: "OMG, let's try to minimize even if it ends up ugly:-/"
[16:43] <vila> jam: did you try to run the associated tests ?
[16:43] <jam> vila: test suite doesn't run either, for other reasons
[16:44] <jam> unittest._WritelnDecorator no longer exists
[16:44] <jam> barry is working on that one
[16:44] <vila> umpf
[16:45]  * vila sings ha ha ha ha, shaving the yack, shaving the yak (on the Saturday's Night Fever music)
[16:45] <jam> looks like the class just moved somewhere, we can grab it from there
[16:45] <jam> shaving the yaaaaaa-aaaaaaa-aaaaaaaa-aaaaaaak
[16:47] <lifeless> lets just drop the WritelnDecorator use :)
[16:49] <jam> lifeless: unittest.runner printErrors calls self.stream.writeln()
[16:49] <jam> lifeless: so it isn't in our code, unless we can override such things in our runners, etc
[16:49] <lifeless> we could stop calling that :)
[16:50] <jam> vila: basically, XMLRPCTransport is no longer compatible with xmlrpclib.Transport
[16:50] <jam> we found a test suite failure
[16:51] <jam> from xmlrpclib....close
[16:51] <jam> it wants a '._connection' attribute (presumably to close it)
[16:52] <mgz> ah, the 2.7 bugs
[16:53] <jam> mgz: yeah
[16:53] <jam> which is also good for Barry to know about, because it directly impacts the chance that 2.7 can be put into the next Ubuntu release
[16:53] <mgz> I'll do the testing one if depending on a newer version of testtools is an acceptable solution
[16:53] <jam> lifeless: the test suite is also failing if lazr.? is not installed
[16:53] <jam> *sigh*
[16:54] <jam> it looks like barry has launchpadlib, but not necessarily the full dependency stack on his 2.7 vm
[16:55] <mgz> what's the rules on where to fix things currently? should I be branching 2.2 or just staying with dev or what?
[16:55] <jam> mgz: branch the thing where you want it to land :)
[16:56] <mgz> does 2.2 want to work with 2.7?
[16:56] <jam> 2.2 is feature/api-frozen
[16:56] <jam> 2.2 is targeted for Maverick, and we'd like to have 2.7 in Maverick
[16:56] <jam> at this point we would *like* it
[16:56] <jam> Subject to the tastefulness of changes to get it
[16:56] <jam> poolie has the final say IMO
[16:59] <vila> wow, installing maverick from the daily build is a breathe, I'm impressed (*again*)
[17:01] <vila> hmpf, boot seems to be even faster than lucid
[17:11] <vila> jam: XMLRPCTransport was meant to be a minimal replacement, it's not surprising it's not compatible anymore
[17:12] <vila> jam: if this becomes too hard to maintain, we may want to switch to launchpadlib instead, I don't know if it has been ported on all platforms though
[17:17] <jam> vila: it is on windows
[17:17] <jam> the main problem is that it is *dog slow*
[17:17] <poolie> hi jam, where did you get off to?
[17:17] <jam> as it does stuff like downloading the WADL definition, extra round trips, etc
[17:17] <vila> jam: good, the hardest part is done then :)
[17:17] <jam> poolie: currently in Mozart 2
[17:17] <jam> w/ barry
[17:18] <poolie> jam/mgz: my main thing for 2.2 is that we should not break plugins that are updated to work with 2.2b4,
[17:18] <poolie> and that we should not break ourselves :)
[17:20] <Meths> Is there a proper way to remove a checkout from my local repo?  Just rming the dir leaves info in the .bzr directory doesn't it?
[18:28] <mgz> okay, one issue down, two more exposed
[18:29] <mgz> ha, second one is less horrible than I thought, but.... man lifeless is going to hate this
[18:37] <maxb> Meths: Yes, but there's no way to get rid of that, currently.
[18:38] <maxb> So just rm the dir
[19:08] <mgz> okay, this is problematic
[19:09] <mgz> bzrlib and the new unittest in 2.7 seem to have different ideas about the arguements to load_tests functions
[19:10] <Meths> maxb: Okay, thanks.
[19:16] <mgz> down to two failures on bt.test_selftest and a bunch of extra spew at the end
[19:47] <vila> mgz: load_tests is specific to bzrlib so we can change it if needed
[19:47] <mgz> well, the problem is it's not any more, likewise other unittest extensions
[19:47] <mgz> there are similar but incompatible implementations of various bits in 2.7
[19:48] <mgz> trying to file bugs for a few bits that can be handled later, but launchpad isn't playing along.
[19:48] <vila> testtools should be fixed then, not bzrlib :->
[19:48] <mgz> well, bzrlib.selftest and bzrlib.TestUtils implements a lot of stuff testtools doesn't
[19:49] <vila> hmm
[19:49] <mgz> is there a way past the +filebug search through all existing bugs?
[19:49] <mgz> because having that timeout on me is just annoying
[19:50] <vila> mgz: on .edge ?
[19:50] <mgz> all I want to do is fill in a few text fields and it doesn't wanna let me
[19:50] <vila> mgz: try disabling the redirection
[19:50] <vila> mgz: prepare everything in your editor and *then* copy/paste :)
[19:51] <mgz> that had a thingy saying it should only be used by "the Launchpad Beta Testers team"
[19:51] <mgz> which I'm pretty sure I'm not in
[19:51] <maxb> there's a sort of cheeky workaround. Keep the summary box blank, click Next, and *then* fill it in
[19:52] <mgz> ah, I'll try that, thanks.
[19:52] <mgz> "There is 1 error." "A summary is required."
[19:52] <vila> mgz: does the host says 'edge' anywhere ? If yes, then you are part of the beta testers team ;)
[19:53] <vila> mgz: go the lp home page and you should be able to disable the redirection for 2 hours
[19:53] <mgz> ah, just a space then will do.
[19:53] <mgz> okay vila, as long as you promise no one will yell at me :)
[19:54] <vila> hehe, I can yell now so you can continue with that done if you want :)
[19:54] <lifeless> mgz: *sigh* testtools
[19:55] <lifeless> mgz: the thing will timeout because fti is doing terrible queries
[19:55] <lifeless> mgz: on edge it will take 14 seconds to timeout, which is better than prod
[19:55] <mgz> does your job change mean I can now direct my launchpad whines at you personally? ;)
[19:56] <lifeless> yes
[19:56] <lifeless> it also means I get to wave my hands and say 'thats not architectural nyah nyah nyah'
[19:56] <mgz> ehehhee
[19:56] <vila> lol
[19:58] <lifeless> mgz: I am interested in whinges and praise.
[19:58] <lifeless> they inform me about the things we need to make easier to fix, and the things we're successful at.
[20:02] <mgz> oh, reminds me - the bug I wanted you to point the launchpad notifications guy at, he might have got the wrong one
[20:03] <mgz> he triaged a minor unrelated one I filed, but I found an existing bug for the email notifications that I commented on
[20:04] <mgz> ...well, it's also minor to be fair, just annoying for inbox management
[20:08] <vila> mgz: like using "My Name <bug#@lp.net>" instead of "My Name <myemail>" when sending a mail to *me* ?
[20:09] <mgz> like that, though that particular doesn't wind me up too much
[20:17] <mgz> what tag should I use for Python 2.7 related issues?
[20:20] <lifeless> python2.7?
[20:20] <mgz> dots are okay?
[20:20] <lifeless> I think so
[20:20] <mgz> I will try.
[20:21] <mgz> seems so.
[20:54] <lifeless> jml: I just found out fuzzyman mangled the load_tests protocol
[20:54] <lifeless> jml: I am feeling infuriated
[20:55] <mgz> such things are only ever discovered after the final release :)
[21:13] <poolie> hi there mgz
[21:13] <mgz> hey poolie.
[21:16] <mgz> poolie: I'm always a little nervous about triage-as-I-file because there's a not-insignificant number of bugs that only I see, so having someone else confirm them makes me feel happier :)
[21:27] <poolie> mgz i know what you mean but i think you'll be right often enough that it's worthwhile over all
[21:27] <poolie> it's just as easy for us to change a bug from confirmed->incomplete or low-> high or high->low as it is from new->something
[21:27] <poolie> anyhow, bed time here
[21:27] <poolie> good nih
[21:27] <poolie> night*
[21:28] <mgz> night!
[23:16] <doug> http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-git-users.html says "Bazaar allows branches to have nicknames, and provides commands to switch branches for you."
[23:16] <doug> what commands are those?
[23:17] <doug> what i want to do is totally a git staple: branch+switch to a throwaway branch to attempt some experimental refactoring
[23:18] <beuno> that would be "bzr switch", although I haven't used it enough to walk you through it
[23:35] <doug> dunno, that doesn't seem to be in wide use or implemented quite like i'd expect
[23:37] <mkanat> doug: Yeah, switch.
[23:38] <mkanat> doug: I use it all the time.
[23:38] <mkanat> doug: I think you might also be thinking of the word "branch" in git terms that don't make sense in bzr.
[23:38] <mkanat> doug: You might want "shelve" instead.
[23:39] <doug> yeah, that might do it.
[23:58] <maxb> doug: The key difference between bzr and git here is that whilst a git branch can just be a name within an existing .git directory, a bzr branch is always identified by an actual user-visible filesystem directory
[23:59] <maxb> a couple of sentences before the one you quoted, in fact :-)