[00:13] <lifeless> spiv: what about
[00:13] <lifeless> def unlock(exc_info=None)
[00:14] <spiv> lifeless: that still requires the caller to do most of the work
[00:15] <spiv> lifeless: to correctly set exc_info you still need a "try: foo(); except: exc_info=sys.exc_info() ... yadda yadda"
[00:20] <spiv> lifeless: there's just no way around the fact that Python gives you no way to determine from a finally block if an except was being raised.
[00:20] <spiv> lifeless: here's the problem in a nutshell: http://rafb.net/p/wy3M5l13.html
[00:22] <spiv> Well, there is one way that might mostly work: introspecting the traceback object to see if the top of the stack is where you expect, i.e. a line inside the relevant try block in the current function.
[00:23] <spiv> Except that could also fail in edge cases, and would be ugly as hell.
[00:23] <spiv> Shorter summary: Python sucks.
[00:23] <lifeless> when was try:finally:except: added?
[00:24] <spiv> try-except and try-finally have been in there since I started using Python.  Or are you asking about a single try with both except and finally?
[00:25] <lifeless> the latter
[00:25]  * jml needs to fix bzr-removable to work with split trees
[00:26] <spiv> 2.5.
[00:58] <meoblast001> hi
[00:58] <meoblast001> how do i download the latest version of a branch?
[01:00] <jml> meoblast001: do you already have a copy of the branch?
[01:00] <meoblast001> yeah
[01:00] <meoblast001> i just want to update it
[01:00] <meoblast001> with the new stuff from launchpad
[01:00] <jml> meoblast001: cd into it and 'bzr pull'
[01:00] <meoblast001> how do i cd into it
[01:00] <meoblast001> like.. the local folder?
[01:00] <jml> meoblast001: that's right.
[01:01] <meoblast001> ok
[01:01] <meoblast001> im downloading it
[01:01] <meoblast001> thanx
[01:01] <meoblast001> just downloading a project of someone i know to see how much it has advanced
[01:02] <jml> cool.
[01:02] <meoblast001> i dont think he's been commiting changes =P
[01:03] <meoblast001> yay... now to worry about the advancement (or lack thereof) of my own project
[01:03] <jml> meoblast001: :)
[01:03] <jml> meoblast001: you can get a fairly good idea of a branch's activity by looking at its web page on Launchpad, btw.
[01:03] <meoblast001> yeah
[01:04] <meoblast001> im thinking about posting my project in Crystal Space forums in the Projects section so maybe someone will come along and help me
[01:04] <meoblast001> i only have 2 ppl on my team
[01:04] <meoblast001> and im the only programmer
[01:04] <ferringb> meoblast001: project being?
[01:05] <ferringb> just curious, haven't heard activity crystal space wise in a long while
[01:05] <meoblast001> its a racing game im making with CS
[01:05] <meoblast001> the game is very crappy so far cuz im the only programmer and i dont have enough time nor experience to write a whole game all on my own
[01:06] <meoblast001> im doing as much as i can and relying on lots of support from #crystalspace
[01:07] <meoblast001> ferringb: heres the Launchpad site https://launchpad.net/nickybearracing
[01:07] <meoblast001> launchpad page rather
[01:07] <meoblast001> i have it precompiled for x86 systems
[01:08] <jml> meoblast001: btw, if you set that branch to be the development focus of the project, people will be able to fetch it with 'bzr branch lp:nickybearracing'
[01:08] <meoblast001> oh
[01:08] <meoblast001> i'll do that
[01:12] <meoblast001> jml: done
[01:14] <jml> meoblast001: cool
[01:14] <meoblast001> =)
[01:15]  * spiv ducks out for some errands and early lunch
[01:17]  * meoblast001 hardly considers himself a programmer
[01:27] <lifeless> jml: perhaps the first branch pushed should become the trunk series by default
[01:31] <jml> lifeless: perhaps.
[01:33] <jml> lifeless: I think it should, but I also think that setting a dev focus should set the "This project officially uses Launchpad for code hosting" flag.
[01:34] <lifeless> jml: btw, I find it weird that I have to opt-in to using bugs etc
[01:34] <jml> lifeless: yes, me too.
[01:35] <jml> lifeless: but I've had that discussion wrt to code twice already, and have too many other things on my plate to try again just now.
[01:50] <lifeless> spiv: ping
[01:54] <Peng_> Awesome, a 15 MB autopack.
[01:55] <Peng_> ...over bzr+ssh
[02:27] <meoblast001> ok.. i messed up on a file and i need to pull the old data back
[02:27] <meoblast001> i need to replace everything i have with everything launchpad has... how do i do that?
[02:27] <bob2> messed up = edited but haven't commited?
[02:27] <meoblast001> yes
[02:27] <meoblast001> i didnt commit
[02:28] <bob2> "bzr revert" will remove all local uncommited changes
[02:28] <meoblast001> k thanx
[02:28] <meoblast001> i just suck at programming so bad that i couldnt solve a very simple problem
[02:40] <spiv> lifeless: pong
[03:05] <lifeless> spiv: so
[03:05] <lifeless> spiv: item keys introduced by
[03:08] <spiv> Ah, that old thing.  What about it?
[03:13] <lifeless> fragmented inventories have components that are not strictly introduced by a revision
[03:26] <lifeless> spiv: further, we don't want to copy already present fragments
[03:30] <lifeless> spiv: but we can't predict what fragments are already present unless we know the edge of the local graph I think
[03:31] <lifeless> spiv: my conclusion is that this api needs to get deprecated and a newer one added
[03:31] <lifeless> that has a cut facility
[03:33] <spiv> lifeless: that'
[03:34] <spiv> s a bit abstract to me.  It sounds plausible, but maybe the simplest thing is to describe the API you're thinking of replacing it with?
[03:35] <lifeless> add a new parameter that lists the surface of revisions we have [that are relevant]
[06:10] <poolie> spiv, hey good catch with the default arguments
[06:10] <poolie> omgpython
[06:15] <spiv> poolie: hooray for code review :)
[06:21] <spiv> abentley: would you mind adding andrew.bennetts@c.c to bundlebuggy as an authorised email address?  (I think it currently expects just andrew@)
[06:28] <poolie> your'e right that making it a parameter is a yagni
[06:43] <spiv> poolie: oh good.  That makes the solution uncontroversial :)
[06:47] <vila> hi all
[07:12] <vila> poolie: ping ?
[07:21] <spiv> vila: oh of course, it's daylight savings here now, so you're turning up an hour later :)
[07:21] <spiv> vila: hi :)
[07:21]  * spiv is about to disappear and go to a yoga class
[07:21] <vila> spiv: oh, since when ?
[07:21] <spiv> Since last weekend.
[07:22] <vila> Haaa, and it's 17:21 your time ?
[07:22] <spiv> Right.
[07:22] <vila> ok
[07:22] <vila> So *you* are leaving one hour earlier :)
[07:22] <spiv> So when you say hello it's time for me to finishing things up for the day :)
[07:23] <vila> Yeah, we should all work at least 13h/day so we can say hi/bye every day :)
[07:24] <spiv> Hah.
[07:25] <spiv> Although it often seems like that's what lifeless does :)
[07:25] <spiv> Thinking of which...
[07:25]  * spiv -> gone!
[09:00] <poolie> markh, are you still around at all? is it hard or easy to make the windows python-based installers?
[09:04] <RAOF> Is my google-fu weak, or is there little documentation about setting up a PQM instance available?
[10:07] <Kinnison> IME, very little
[10:07] <Kinnison> Although I thought there was a GSoC student working on PQM, so perhaps he produced some?
[10:21] <RAOF> Kinnison: That's kinda annoying.  Maybe I'll just wait for Launchpad to grow a PQM instance for me :/
[10:22] <RAOF> Heh.  Or I'll bug Rob & Jono mercilessly!
[11:12] <eMBee> a group, and then make files readable by that group
[11:12] <eMBee> ooops
[11:15] <hno> Hmm... something is fishy in bzr 1.7.1. Running 1.7.1 both on cliend and server, and after a relatively small remote change "bzr update" suddenly downloaded 11 MB of data. Total remote repository size is 70 MB and increased by some KB only since the last bzr update..
[11:26] <spiv> hno: if it's via bzr:// or bzr+ssh://, try using -Dhpss next time and see if the ~/.bzr.log file gives more info about what's going on.
[11:26] <hno> spiv: It's bzr+ssh
[11:26] <spiv> hno: my guess is that it's fetching most of the remote index files (how big is .bzr/repository/indices?) for some reason
[11:27] <spiv> hno: if so, then there are various improvements planned that should help that.
[11:27] <hno> indicies is a total of 7 MB.
[11:33] <Peng_> It's dumb enough to use 11 MB of bandwidth for 7 MB of indexes plus everything else.
[11:37] <hno> I don't get why it at all need to fetch the index files in a bzr update.. There is no local modifications and the local head is an ancestor of the remote head. Better to just ask for a bundle from the local head revision to current head of the remote branch.
[11:39] <Peng_> It may be using the indexes to find out which revisions such a bundle would include.
[11:54] <hno> Peng_: Well, it could do this optimistically by first asking based on the local revision.. or keep track of which revision that was last updated/merged.. But that's my outside view. I don't really know how deep checks bzr needs to do to find a common ancestor.. maybe revision number (the long version) isn't sufficient.
[11:56] <hno> or revision-id which is the more proper term..
[11:56] <Peng_> Right. I'm sure it can (and does) do it more efficiently than that. I was just saying.
[11:57] <Peng_> If it's reproducable, use -Dhpps like he suggested to help diagnose it.
[11:58] <hno> Peng_: Will try to reproduce it. At the moment both my local repositories have already updated.
[12:07] <spiv> hno: there are several known inefficiencies.  Ideally it should be a matter of finding out what the remote revision is with a single round-trip, finding out how much is missing from the local repo with a couple of quick round trips, and then requesting those revisions in a single stream.
[12:07] <spiv> hno: there's various reasons why that's not quite the case at the moment, but we're working on it.
[12:08] <BjornW> hi, what would be the bzr equivalent of: svn export --force [SOURCE] [DESTINATION]
[12:08] <hno> spiv: Thanks.
[12:10] <spiv> BjornW: "bzr export SOURCE DESTINATION" probably.
[12:10] <spiv> I'm not sure what effect --force has on svn export.
[12:11] <BjornW> spiv: it will overwite exisiting exports
[12:11] <BjornW> spiv: Mhhhm I cannot overwrite an export with bzr?
[12:12] <spiv> Hmm, it may be "bzr export DESTINATION SOURCE", actually.  Check the docs :
[12:12] <spiv> :)
[12:13] <spiv> Hmm, doesn't look like it.  You could export to a tar file and then let tar do the overwriting.
[12:13] <hno> Hmm.. almost could reproduce it. Created a new repository with a branch some revisions back, and then did a bzr pull from the remote. But it fetched "only" 4MB this time.
[12:13] <spiv> BjornW: it would be a reasonable feature to add, I think.  File a bug.
[12:14] <BjornW> spiv: will do, thanks for your help
[12:29] <abentley> spiv: done
[12:33] <hno> Indeed. There is lots of index accesses.
[12:34] <Elvanor> Hello, I am searching for a VCS with the following features: 1) deal correctly with binary files, 2) limit the total repository file size (by keeping only a limited number of versioned items)
[12:34] <Elvanor> I was told by the git guys to come here...
[12:34] <Elvanor> So can bazaar do what I need?
[12:35] <Elvanor> all my source code is currently in SVN, I am happy with that, but I want to setup a separate tool for backing up binary files: PDF files, GIMP images
[12:38] <bob2> 1 can be done by everything bar cvs
[12:38] <spiv> abentley: thanks!
[12:48] <Elvanor> bob2: yes but 2) is harder
[12:49] <Peng_> You mean throwing out old history?
[12:59] <Elvanor> Peng_: yes
[12:59] <Elvanor> automatically, if possible
[13:02] <Peng_> Yeah...not so possible with bzr.
[13:02] <Peng_> (I mean, it is /possible/, with tons of rebase or something, but it's not intended or efficient.)
[13:07] <Elvanor> Peng_: do you any other system allowing this easily?
[13:07] <Elvanor> git people told me it would be easy with bazaar
[13:15] <Peng_> I wonder why the git people thought that?
[13:16] <james_w> you can just delete the old revisions and leave ghosts in the mainline I guess
[13:17] <Elvanor> Peng_: someone said: well, do check out bzr, it can certainly prune more easily as its commit IDs are just UUIDs
[13:27] <Peng_> james_w: That's safe?
[13:27] <Elvanor> Maybe what I need is more a backup system... but I want the ability to share files between users with locks, commits etc
[13:28] <Peng_> james_w: But won't it need them to reconstruct stuff?
[13:29] <Peng_> Elvanor: Oh. That git user is correct. Part of bzr's design does theoretically make it easier to mutate history, at least in some ways.
[13:29] <Peng_> (But it does hash at least some things too, and what would it do if it came across two differing revisions with the same ID?)
[13:29] <james_w> Peng_: yeah, just deleting it isn't safe, but it's possible
[13:30] <Peng_> (Which doesn't apply to mainline ghosts, which would work,  Iguess.)
[13:31]  * Peng_ dies of parenthesis abuse.
[14:29] <Lieven1> does anyone know from where I can get the latest source code of tortoisebzr?
[14:30] <Lieven1> I tried lp:tortoisebzr, but it seems to be really outdated
[14:34] <jelmer> hi Lieven1
[14:34] <jelmer> markh, ^
[14:35] <jelmer> Lieven1, I think tortoise is part of bzr.dev now, but I'm not entirely sure
[14:39] <Lieven1> I don't think it is, or at least, I can't find it
[15:26] <CardinalFang> Hi all.  My group uses a very large bzr tree, and we often try to speed up our actions by branching two trees at the same time or pushing two or more trees at the same time.  I don't have specifics right now.  For branching or updating, we sometimes get index-file-missing errors, and when pushing one of the pushes hangs.  I suspect that there's some shared-repo data that isn't locked correctly, locally or remotely.  I don't have
[15:26] <CardinalFang> enough to file a bug, yet, but I just want to remark about it in case someone has a flash of insight.
[15:27] <CardinalFang> Expect a full bug or two filed in a week or so.
[16:32] <jam> CardinalFang: bug #153786 most likely
[16:33] <CardinalFang> hmm.
[16:40] <ccxCZ> Hi, does file id change when it's moved renamed?
[17:20] <Peng_> ccxCZ: no
[17:20] <Peng_> ccxCZ: That's the point of file IDs. :P
[18:00] <pekuja> is it possible/viable to host a bazaar repo on a server with no bazaar installed?
[18:01] <cody-somerville> pekuja, sure
[18:01] <pekuja> the idea is to have a repo in the public_html of my shell account so that I can push through ssh and others can pull through dumb http
[18:02] <pekuja> so should I basically do a clone of my repo on my local machine and copy it over to the server? should something like that work?
[18:03] <pekuja> sorry if this is really obvious. I'm reading the user guide but I'm kinda tired tonight :-/
[18:03] <cody-somerville> pekuja, just do a bzr push via the sftp transport layer
[18:03] <pekuja> that will create the clone?
[18:03] <cody-somerville> yup
[18:03] <pekuja> cool, that sounds super easy
[18:04] <cody-somerville> pekuja, it is :)
[18:04] <cody-somerville> pekuja, you can also use launchpad for hosting your branches if you'd like
[18:06] <pekuja> oh, right... I guess that's an option. it's not really a project of any public interest though. just using the vcs for coding a university course project type thing
[18:11] <fynn> Hi. Suppose I took a .bzr directory renamed it to "foo", and moved it to ~/bar. is there a way to recreate all the monitored from "foo" without changing its name to .bzr?
[18:12] <fynn> (I could rename it to .bzr and do "bzr revert", but I'm wondering if there's a solution without the rename stage.)
[18:13] <cody-somerville> fynn, What are you *really* trying to accomplish?
[18:14] <fynn> cody-somerville: I'm backing up file trees by making them into Bazaar branches, then archiving the root .bzr directory.
[18:14] <fynn> cody-somerville: right now, the final stage of a restore involves a "rename the 'backup' directory to '.bzr'" step.
[18:15] <james_w> fynn: it may be possible with some python
[18:15] <fynn> I was hoping to eliminate that step, so as to make the process more elegant.
[18:15] <fynn> james_w: OK, thanks. I might hack that then.
[18:15] <james_w> fynn: but no, it's not just an environment variable or command line switch or anything
[18:15] <fynn> *nod*
[18:16] <fynn> also, as a bzr newbie, just to make sure:
[18:16] <fynn> james_w, cody-somerville: do any of you guys see a problem with using bzr for (version-controlled) backups in that way?
[18:17] <fynn> e.g. could I possibly encounter any issue with restoring a perfect copy from such a backup?
[18:17] <james_w> I don't think so
[18:18] <fynn> alright... btw, if I have a source tree ~/foo, and I make it into a Bazaar branch (with "bzr init; bzr add; bzr ci"), the *only* change to ~/foo is the creation of ~/foo/.bzr, and the directories/files under it?
[18:19] <james_w> yup
[18:19] <james_w> .bzrignore if you do "bzr ignore something"
[18:21] <fynn> james_w: so outside of the creation of ~/foo/.bzr and ~/foo/.bzrignore themselves, any further VCS work, no matter how many subdirectories and files are monitored beneath ~/foo, and no matter how many of them I choose to ignore, will only happen inside ~/foo/.bzr and ~/foo/.bzrignore themselves?
[18:21] <james_w> yup
[18:22] <fynn> james_w: thanks a lot. that's such a relief after .svn creating itself in _every monitored subdirectory_.
[18:22] <fynn> looks like my new backup scheme with bzr is viable.
[18:43] <fynn> OK, something I don't get: inside the branch ~/foo I have a file ~/foo/bar.py that I now want to ignore.
[18:43] <fynn> but commanding "bzr ignore bar.py" issues a warning about it already being monitored, and doesn't ignore it.
[18:43] <fynn> so how should it be done?
[18:44] <fullermd> Ignore doesn't unversion a file that's already versioned; it just prevents 'add' from automatically adding it (and 'status' showing it unknown, etc)
[18:44] <fullermd> You'll have to use bzr rm to unversion it.
[18:44] <fullermd> (possibly with --keep of course)
[18:46] <fynn> fullermd: I see, thanks.
[18:46] <fynn> --keep is nice.
[18:46] <fullermd> I have it aliased to be the standard 'bzr rm' behavior.
[19:08] <fynn> fullermd: apropos aliases: is there a way to make "bzr st -SV" the default behavior of "bzr st"?
[19:09] <fynn> i.e. set a persistent configuration setting that would implicitly add the -SV flags to every "bzr st" command?
[19:10] <fullermd> You could just alias st to 'stat -SV'
[19:18] <fynn> yeah, I guess that's the best solution.
[19:23] <fullermd> Well, I've got rm aliased to rm --keep, and missing aliased to missing --line and such   :p
[19:36] <fynn> fullermd: "aliased" as in bash alias, right?
[19:36] <fullermd> No, bzr alias.
[19:36] <fullermd> bzr help alias
[19:37] <fynn> bzr: ERROR: No help could be found for 'alias'. Please use 'bzr help topics' to obtain a list of topics.
[19:37] <fullermd> Mmm.  What version do you have?
[19:37] <fynn> 1.5
[19:37] <fullermd> Looks like the 'alias' command came in with 1.6.  They've been supported for ages before that though; you just have to set them manually in the config file.
[19:38] <fynn> cool, thanks.
[19:38] <fullermd> Make an [ALIASES] section in your ~/.bazaar/bazaar.conf, and add a line that says "st = stat -SV"
[19:38] <fullermd> There's a wiki page about it I think.
[19:38] <luks> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#using-aliases
[19:38] <fynn> that's what I like so much about bzr: so many features, so convenient.
[19:38] <fynn> and organized quite elegantly too.
[19:40] <abeaumont> hmmm, i have an error with ftp transport and mode, i've seen a bug report and patch https://bugs.launchpad.net/bzr/+bug/259855 , but i'm still getting the same problem :?
[19:41] <fynn> fullermd, luks: that worked, thanks a bunch.
[19:56] <abeaumont> i also have added a feature to bzr upload plugin, is there any developer of this plugin around?
[19:59] <beuno> abeaumont, yes
[19:59] <beuno> hello
[19:59] <beuno> you can upload the branch
[19:59] <beuno> fle a merge request
[19:59] <beuno> and we'll review it to get it into the tree  :)
[20:00] <fynn> can I have a different bazaar.conf apply to different repos?
[20:01] <abeaumont> beuno: ok, I'll do that
[20:01] <beuno> thanks abeaumont
[20:21] <abeaumont> beuno: done :) i hope i did everything right, otherwise just tell me (i'm new to launchpad)
[20:21] <beuno> abeaumont, did you file the merge request against trunk?
[20:25] <awilkins> Can anyone things of commands that should take siblings in the same way that "switch" does (apart from merge, which is the top of my list)
[20:27] <fullermd> pull?  missing?  push?  diff?  stat?  bind?  reconfigure?  send?
[20:27] <fullermd> Really, pretty much ANYTHING that can refer to a branch.
[20:27] <abeaumont> beuno: oh, no, forgot that
[20:28] <abeaumont> beuno: ok, done
[20:28] <beuno> abeaumont, got it!  will get to it in a few hours.  Many thanks!
[20:29] <abeaumont> beuno: perfect, thanks!
[20:30] <awilkins> !wake aeris
[20:30] <awilkins> Sorry bot
[20:53] <fynn> can I have a different bazaar.conf apply to different repos?
[20:54] <Odd_Bloke> fynn: You might want to look at locations.conf.
[21:00] <fynn> Odd_Bloke: thanks, looks to be just what I was looking for.
[21:31] <spsneo> hey how can I use bzr client behind http proxy?
[21:31] <spsneo> please help
[21:33] <Spaz> magic.
[21:33] <spsneo> Spaz: hey can u help me ?
[21:33] <Spaz> set http_proxy in your environment
[21:33] <spsneo> ya I have already done that
[21:34] <Spaz> http://bazaar-vcs.org/ConfiguringBzr#head-39a4bf80d496af410e013585de6268ca55928d38
[21:34] <Spaz> if it doesn't work, i don't know what to tell you :p
[21:34] <Spaz> sorry
[21:35] <spsneo> Spaz: do u know anybody who would help me
[21:35] <Spaz> spsneo, what is your problem with it
[21:35] <Spaz> if you set http_proxy (export http_proxy="http://proxy.crap.here") then it should work
[21:36] <spsneo> i am trying this : bzr branch lp:inx trunk
[21:36] <Spaz> if not then it sounds like your proxy is either misconfigured or something is broken
[21:36] <Spaz> that is a local operation i believe
[21:36] <spsneo> but it gives a long list of errors
[21:37] <Spaz> hm
[21:37] <Spaz> pastebin them please
[21:37] <spsneo> Spaz: i guess this is the command to get the branch from launchpad
[21:38] <Spaz> hm
[21:38] <spsneo> Spaz: http://pastebin.com/d65492841
[21:38] <Spaz> bzr: ERROR: socket.gaierror: (-5, 'No address associated with hostname') <-- that is all i needed to hear
[21:39] <Spaz> the hostname doesn't resolve.
[21:39] <Spaz> meaning you're using a hostname that is invalid
[21:39] <spsneo> normally what is the method to get a copy of trunk from lp ?
[21:40] <Spaz> spsneo, depends
[21:41] <Spaz> what project do you wish to check out?
[21:41] <spsneo> inx on lp
[21:41] <Spaz> odd...
[21:42] <Spaz> spsneo, it sounds like an issue with your proxy
[21:42] <spsneo> Spaz: I also thought so
[21:44] <spsneo> Spaz: so is there no solution?
[21:46] <Spaz> spsneo, don't use an http proxy
[21:46] <Spaz> spsneo, or fix your http_proxy environmental variable
[21:46] <spsneo> Spaz: I am in an university
[21:46] <Spaz> hm
[21:46] <Spaz> i would bet $10 that your http_proxy variable is set wrong
[21:46] <spsneo> actually I am behind a firewall also
[21:47] <spsneo> hehe no ways
[21:47] <Spaz> export http_proxy="http://proxy.url.org:port" ?
[21:47] <spsneo> svn is working fine
[21:47] <Spaz> is it in that format
[21:47] <Spaz> hm
[21:47] <spsneo> yaya
[21:47] <Spaz> sounds like a possible bug
[21:48] <Spaz> that or your DNS server might be down
[21:48] <Spaz> not much i can do in either case spsneo
[21:48] <spsneo> ya its in the format : http_proxy="http://user:pass@proxy.url.org:port"
[21:48] <Spaz> ah ok
[21:48] <Spaz> is the actual address resolving?
[21:48] <Spaz> run host proxy.url.org or such
[21:48] <spsneo> Spaz: well I am behind a firewall as well which allows only http and https
[21:55] <james_w> bug 186920
[21:55] <james_w> too late
[22:19]  * mwhudson hmms
[22:47]  * mwhudson gruntles
[22:50] <Peng_> ?
[22:57] <mwhudson> Peng: i want to add a keyword parameter to Branch.open/BzrDir.open_branch without breaking all branch implementations
[22:58] <mwhudson> (well, branch format implementations i guess i really mean)
[22:59] <Peng_> Oh
[23:02] <jam> mwhudson: good luck with that
[23:02]  * fullermd would like a pony when you get done with that.
[23:02] <jam> I think you have to create a new api that calls back, if you *really* don't want to break compatibility