[00:01] <lifeless> meoblast001: bzr help hooks | less
[00:01] <meoblast001> lifeless: do you mean post_change_branch_tip?
[00:01] <lifeless> probably, yess
[00:04] <lifeless> meoblast001: http://wiki.bazaar.canonical.com/BzrPlugins is a reasonable list of plugins - most, not all
[00:04] <lifeless> meoblast001: there is publish-bot which does irc already
[00:05] <meoblast001> ok, thanks
[00:07] <maxb> mathrick: *shrug*  bzr branch lp:dulwich
[00:18] <lifeless> mathrick: I think its reasonable for trunk to have a dependency on trunk of something else
[00:18] <lifeless> particularly when they have a close relationship
[00:19] <mathrick> yeah, I know
[00:21] <mathrick> now it's reasonable to depend on the trunk, but the trunk isn't 0.5.0 either
[00:22] <mathrick> I guess the root problem is that samba.org repos are down
[00:23] <toobaz_> Hello... has the "svn-push" command, which is referred in several (old) pages, disappeared? I installed bzr-svn, but I get 'bzr: ERROR: unknown command "svn-push"'...
[00:23] <mathrick> toobaz_: just use push
[00:23] <mathrick> it's not needed anymore
[00:23] <toobaz_> ooh
[00:23] <toobaz_> that's nice
[00:23] <toobaz_> thanks
[00:23] <mathrick> no problem
[00:24] <mathrick> okay, so it is 0.5.0, but for whatever reason it's 0.4.1 when I build a deb out of it
[00:33] <lifeless> mathrick: perhaps debian/changelog is stale :P
[00:34] <lifeless> mathrick: or its been given a pre-0.5.0 version because 0.5.0 isn't released
[00:35] <mathrick> lifeless: nah, it was eggs installed by bzr-git overriding the system-wide dulwich
[00:37] <mathrick> okay, now I've got a crasher
[00:39] <mathrick> http://www.pastebin.com/f187cd9fd
[00:49] <lifeless> mathrick: can you say my name - testing a script
[00:49] <mathrick> lifeless: test
[00:50] <lifeless> great thanks
[00:50] <mathrick> no problem
[00:50] <mathrick> any idea what's wrong in my crash?
[00:51] <lifeless> not offhand
[00:51] <lifeless> have you looked at bzr-gitbugs?
[00:51] <Peng> There have been as_dict-related bugs in the past, but I don't remember it being in rio.
[00:53] <mathrick> lifeless: nope, lemme try that
[00:54] <Peng> mathrick: How up-to-date are bzr/bzr-git/dulwich?
[00:54] <mathrick> pulled 30 mins ago
[00:54] <mathrick> well, bzr-git and dulwich
[00:54] <mathrick> bzr is 2.1.0
[00:54] <mathrick> 2.1.0rc2 to be exact
[00:55] <mathrick> https://bugs.launchpad.net/bzr-git/+bug/489649 <-- what do you know
[00:55] <mathrick> I reported a similar bug already
[00:55] <lifeless> mathrick: try again please
[00:55] <mathrick> somehow I always hit bugs in jelmer's code, I dunno how that works
[00:55] <lifeless> (my nickname)
[00:55] <mathrick> lifeless: pokety
[00:56] <lifeless> \o/
[00:56] <lifeless> gui notifications setup
[00:56] <lifeless> I might rewrite it in python at some point, but this is good enough for now
[00:58] <mathrick> lifeless: oh, so it popups a bubble with what's been said?
[00:59] <Peng> With me it would usually be an iRPG or spam in #freenode. :-P
[00:59] <mathrick> preferably without being all stupid and doing seventy things in my tray none of which I care about?
[00:59] <lifeless> mathrick: yeah
[00:59] <mathrick> lifeless: can I have it?
[00:59] <mathrick> and what's it in, if not python?
[00:59] <lifeless> of course
[00:59] <lifeless> perl and bash
[01:00] <mathrick> aha, lemme check if I have perl here
[01:00] <Peng> But do you have bash? :D
[01:00] <mathrick> hmm, let's check something first
[01:00] <mathrick> lifeless: what IRC client? :)
[01:00] <lifeless> irssi
[01:00] <mathrick> ah, right, I sort of assumed it'd be xchat
[01:01] <mathrick> lifeless: hmm, say something to me
[01:01] <lifeless> http://www.google.com/reader/shared/robert.collins?hl=en - the first link explains it
[01:01] <lifeless> mathrick: yo
[01:01] <mathrick> oh nice, it's built into xchat nowadays
[01:01] <mathrick> thanks
[01:02] <lifeless> xchat has notifications built in
[01:02] <lifeless> :)
[01:02] <mathrick> yah, I'm just used to it being incredibly retarded
[01:02] <mathrick> but they fixed it it seems
[01:02] <mathrick> xchat plugins have a long and proud history of doing everything but the things you want
[01:02] <mathrick> and doing things you don't want too
[01:03] <lifeless> mathrick: all of xchat fits that description to me :)
[01:04] <mathrick> yeah, but irssi is even more brain-damaged
[01:04] <mathrick> so really it's the lesser evil
[01:04] <lifeless> well, it has a rather compelling advantage
[01:16] <mathrick> hey jelmer
[01:16] <mathrick> https://bugs.launchpad.net/bzr-git/+bug/489649
[01:16] <jelmer> hi mathrick
[01:17] <lifeless> jelmer: please don't auto-op :)
[01:17] <mathrick> jelmer: I hit that bug again
[01:17] <jelmer> lifeless, I'm not doing anything
[01:17] <jelmer> lifeless, the network has started doing that to me recently
[01:17] <lifeless> jelmer: its a service setting
[01:17] <mathrick> jelmer: also, your samba.org repos are down, which I found out trying to get dulwich
[01:17] <jelmer> mathrick, they seem alright to me
[01:17] <lifeless> jelmer: I don't know which mode flag in particular, but its controllable
[01:18] <jelmer> mathrick, http://people.samba.org/bzr/jelmer/dulwich/trunk/
[01:18] <jelmer> lifeless, I wonder why it's suddenly started giving me ops here though
[01:18] <mathrick> jelmer: odd, both hang for me
[01:18] <jelmer> I haven't talked with nickserv or chanserv in ages
[01:18] <mathrick> I wonder if my ISP is doing something funny
[01:18] <lifeless> we expanded the nicks with op access
[01:18] <jelmer> ahh
[01:19] <lifeless> to be most everyone with commit access
[01:19] <mathrick> by "both" I mean git and bzr repos
[01:19] <mathrick> jelmer: also, the github / gitorious mirrors contain no refs, sez git
[01:19] <lifeless> :>
[01:19] <lifeless> later
[01:19] <jelmer> mathrick: I think there's something wrong on your end then..
[01:20] <jelmer> mathrick: git has no problems cloning the dulwich git repo here either
[01:20] <mathrick> okay, I'll assume it's whatever my ISP is screwing up then
[01:21] <mathrick> every once in a while random pages stop responding it seems
[01:22] <jelmer> mathrick, if you hit this during pull, it is when pulling from a remote git repo into a git repo using bzr?
[01:24] <mathrick> yes
[01:27] <mathrick> jelmer: somehow I seem to hit these things in your code all the time
[01:28] <jelmer> mathrick: bzr-git's working tree support has never really been a focus
[01:29] <mathrick> by working tree you mean operating on git checkouts with bzr?
[01:29] <jelmer> mathrick: yeah
[01:29] <mathrick> I see
[01:29] <mathrick> it'd be nice to be able to use bzr as a saner UI to git
[01:29] <jelmer> mathrick: in that case you'd probably want a bzr working tree with a git branch/repo
[01:30] <jelmer> mathrick: rather than a git working tree, which uses an index - something that doesn't map to bzr's UI very well
[01:30] <mathrick> jelmer: sure, and does pushing to git work in this case?
[01:30] <jelmer> mathrick: yeah
[01:30] <mathrick> so I can just push to github and be a happy man?
[01:30] <jelmer> Well, ideally
[01:31] <jelmer> that's also a situation that's not heavily tested
[01:31] <mathrick> so what is tested then? :)
[01:31] <jelmer> but I'm keen to fix bugs
[01:31] <jelmer> mathrick: using bzr-git to push from and to pull git repositories
[01:31] <jelmer> into native bzr branches
[01:31] <mathrick> jelmer: push from as in cd git-checkout; bzr push lp:some-project ?
[01:32] <mathrick> jelmer: I'll give it a go then I guess
[01:32] <jelmer> mathrick: the other way around generally
[01:32] <mathrick> then I don't understand "push from"
[01:32] <jelmer> mathrick: bzr branch git://github.com/bla && cd bla && hackhack && bzr dpush git+ssh://github.com/bla
[01:32] <jelmer> (or a local git repo rather than a remote one)
[01:33] <jelmer> mathrick: anyway, that isn't to say we shouldn
[01:33] <jelmer> 't support working in a git working tree
[01:33] <mathrick> jelmer: ah, that's the thing I wanted to do, I understood it was what was poorly tested
[01:33] <jelmer> it's just not something that we've focussed on so far
[01:33] <mathrick> right
[01:33] <jelmer> mathrick: that's not what you're doing at the moment
[01:34] <mathrick> I know that, but I was asking if I can push from a bzr-git branch into a github repo without problems
[01:34] <jelmer> ah, sure
[01:34] <mathrick> but speaking of git, any progress on having git-style in-place branches?
[01:34] <jelmer> well, s/push/dpush/
[01:34] <mathrick> aha, good to know
[01:34] <jelmer> mathrick: co-located branches are in progress...
[01:34] <mathrick> I must say they're hellishly convenient when debugging
[01:35] <mathrick> because I don't need to update any paths, I just checkout upstream and restart
[01:36] <mathrick> jelmer: where can I track the progress?
[01:36] <jelmer> mathrick: nowhere really, it's just branches landing that add more support towards it
[01:36] <mathrick> I see
[01:36] <mathrick> so it's not something that can be easily added with a plugin?
[01:37] <jelmer> mathrick: well, there is a plugin that adds it (bzr-colo)
[01:37] <jelmer> but I'm working on supporting it in the core
[01:37] <mathrick> ah
[01:37] <jelmer> and for e.g. git repositories
[01:37] <mathrick> how robust is the plugin?
[01:38] <jelmer> I have no idea
[02:12] <mathrick> jelmer: http://www.pastebin.com/f37cafafb
[02:12] <mathrick> I don't think this happened before I updated bzr-git
[02:12] <jelmer> mathrick: It's because you updated bzr
[02:12] <jelmer> mathrick: it's fixed in bzr.dev
[02:12] <jelmer> and 2.1.0
[02:13] <mathrick> oh
[02:13] <mathrick> is 2.1.0 out?
[02:13] <jelmer> yeah
[02:13] <mathrick> nice
[02:13]  * mathrick updates
[02:18] <mathrick> hmm, where am I supposed to get it? PPA stopped updating (policy change as I understand), but karmic doesn't have anything past the rc2
[02:20] <jelmer> I'm not sure
[02:41] <jelmer> lifeless: my ops should be fixed now..
[02:41] <jelmer> \o/
[02:44] <MTecknology> What does this mean? Fetching revisions:Inserting missing keys:
[02:44] <Peng> It's...downloading stuff. Or uploading, as the case may be.
[02:45] <MTecknology> I meant this part "Inserting missing keys"
[02:46] <jelmer> in this case it is adding keys for ghosts
[02:47] <jelmer> MTecknology: Is the branch you are pulling down perhaps imported from baz originally?
[02:47] <MTecknology> launchpad
[02:47] <jelmer> ah
[02:47] <jelmer> Launchpad does indeed have a lot of ghosts in its history
[02:47] <jelmer> I'm not sure why adding dummy keys for them requires so much time though
[02:48] <MTecknology> what's a ghost?
[02:51] <jelmer> it's a revision to which references exist in the history, but which is not actually present
[02:51] <jelmer> ghosts could easily be created in baz
[02:52] <MTecknology> oh
[02:52] <MTecknology> so is bzr the reincarnation of baz?
[02:53] <wgrant> Pretty much.
[02:54] <Peng> bzr is a completely different codebase, but it was created by the same people as baz..
[02:54] <Peng> Well.
[02:54] <Peng> baz is a fork of tla, but still.
[02:54] <MTecknology> how do git and bzr compare in features?
[02:56] <mathrick> MTecknology: http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html
[02:56] <mathrick> IMHO, git is absolutely insane in terms of UI, which is a deal breaker
[02:57] <mathrick> whereas bzr simply works and does what I want
[02:57] <MTecknology> nice reading for me
[03:00] <MTecknology> thanks :)
[03:02] <spiv> IIRC, "missing keys" refers to the way bzr does fetches: in the first pass it optimistically grabs what is probably most if not all of the data for the revisions being transferred, and then checks if any records (e.g. file versions, parent inventories, etc) that are required for the new revisions are still missing; if there are, it does a second pass small fetch to grab those items the first pass missed.
[03:04] <spiv> (It's hard to calculate the full set of data up front because that requires inspecting the direct records for the new revisions, but the client can't do that until it has received them, and the server can't do it precisely because it doesn't know exactly what records the client already has)
[03:08] <MTecknology> So far what I'm seeing is that bzr is simple, easy, flexible and git lets you perform about any task but isn't very friendly
[03:34] <wgrant> Should a push really be CPU bound? I'm just pushing a Launchpad branch to a local Launchpad instance, and the bzr process doing the push is eating an entire core.
[03:34] <wgrant> The remote side is also sometimes eating the other core.
[03:35] <wgrant> (bzr 2.1.0 local, 2.1.0rc2 remote)
[04:01] <spiv> wgrant: it's a known issue, I forget exactly what the analysis is
[04:01] <spiv> wgrant: some combination of searching indices, decompressing and parsing records, and recompressing them.
[04:02] <wgrant> spiv: I see.
[04:02] <spiv> wgrant: I'd bet jam knows the details
[04:38] <MTecknology> trying to make this launchpad system run it kicking my butt
[04:38] <wgrant> MTecknology: It's still not working?
[04:38] <MTecknology> nope
[04:38] <MTecknology> make run only throws out one error and one warning
[04:39] <wgrant> pastebin
[07:04] <lifeless> spiv: ping
[07:04] <lifeless> spiv: I've been pondering command cleanups.
[07:05] <lifeless> spiv: I think there are a few things that can be improved in the current implementation; mainly that a public method (run) is no longer safe to call.
[07:06] <lifeless> spiv: so I'm wondering if, instead, we should say 'define _run_with_cleanups' for methods that use cleanups, and not support them on 'run' at all
[07:06] <lifeless> spiv: the calling logic could determine which method to execute, or something like that
[07:06] <spiv> lifeless: as a way to ease backwards compat for plugins?
[07:07] <spiv> I think eventually most command implementations will want to use add_cleanup, so it would be good to make sure that end state will be reasonably clean.
[07:07] <lifeless> to raise it level on rusty's interface safety sacle
[07:08] <spiv> Yeah.  It does suck that 'run' isn't necessary safe to call right now.
[07:08] <lifeless> and the end state is that it will usually /not/ be safe to call
[07:08] <lifeless> so I'd like it to look unsafe
[07:08] <spiv> Right.
[07:09] <spiv> If you feel that raising some sort of error that says deprecated/not-implemented/please-use-other-method-instead will be nicer than the status quo, then let's do that.
[07:09] <lifeless> so I'm proposing that we deprecate run(), add _run() or something more clear
[07:10] <lifeless> migrate commands over as they want cleanups
[07:10] <lifeless> or perhaps have
[07:10] <spiv> Hmm.
[07:10] <lifeless> add_cleanup error if you used run()
[07:10] <spiv> Do we need to add a new method instead of using run_direct?  I'm forgetting details already.
[07:10] <spiv> I think add_cleanup erroring if you used run would be bad.
[07:10] <spiv> Because then you'll fail to cleanup!
[07:11] <lifeless> spiv: well, you won't ever ship it to users though :)
[07:11] <lifeless> spiv: because it would blow up early. [kindof my point]
[07:11] <spiv> lifeless: haha, I admire your optimism :)
[07:11] <lifeless> spiv: by 'used run' I mean 'the command was defined with run()' not 'a client of the api called run()'
[07:11] <spiv> I would rather blow up even earlier (by making run fail to, er, run).
[07:12] <lifeless> spiv: sure
[07:12] <spiv> But if you get to the point of the code trying to execute add_cleanup, then it's too late to behave gracefully, because there must be something to cleanup at that point :)
[07:12] <lifeless> so there are a few questions: should we have an external keyword-function for running a command
[07:13] <lifeless> its kindof nice for close testing, but I don't think we use it much that way
[07:13] <spiv> I think for convenience of writing tests it'd be nice.
[07:13] <lifeless> and its hard for decorating
[07:13] <spiv> But yeah, check if any of our tests actually need that.
[07:13] <spiv> brb, baby
[07:13] <lifeless> because the signature changes between core and plugin, often.
[07:37] <lifeless> spiv: I can mail you ifyou like
[07:37] <lifeless> I don't think babies fit into 'right back' :P
[07:41] <MTecknology> the only thing that really annoys me about bzr is that you can't just have a branch on a server and add users to a group so they can access it, you pretty much have to create a new user and add peoples ssh keys to that user account to let multiple people work on a project
[07:41] <MTecknology> I'm guessing that's because of it's decentralized nature
[07:42] <lifeless> uhm
[07:42] <lifeless> it should work; in what way doesn't it?
[07:42] <lifeless> I mean, you need a filesystem that will preserve group access properly; and the default umask on unix won't
[07:43] <MTecknology> lifeless: this is what I came up with the last time I tried - http://profarius.com/content/creating-your-own-bazaar-server
[07:44] <lifeless> theres also a helper script in the bzr distribution to do group based access I believe
[07:44] <MTecknology> oh. I'll have to look at that
[07:45] <lifeless> dunno what it does ;)
[07:45] <MTecknology> :P
[07:45] <MTecknology> where can I find that at?
[07:45] <lifeless> its probably in the package in /usr/li/bzr
[07:45] <lifeless> otherwise in contrrib/ in the source
[07:46] <MTecknology> alrighty, I'll try that out
[07:46] <MTecknology> so far that
[07:46] <MTecknology> 's the only thing about bzr that I'm not enjoying
[08:09] <lamalex> would be nice if bzr init-repo had some flags to set those automatically
[08:14] <lifeless> spiv: also if you felt up to reviewing my subunit  test patch in the bzr merge queue, that would <3 brownie points
[08:32] <spiv> lifeless: mail is good
[08:33] <spiv> lifeless: also, I don't really look after any significant plugins myself, so perhaps I don't have the best perspective on what the requirements are... someone on the mailing list may want to chip in
[08:33] <spiv> lifeless: I'll take a peek at the subunit patch, see if it looks small enough.
[08:34] <spiv> (small enough to fit between baby moments :)
[08:56] <lifeless> spiv: its very small
[08:57] <lifeless> spiv: is add_cleanup in 2.1 ?
[08:57] <lifeless> [for commands]
[16:34] <Benathome> hi - can someone help - I think my osx install of bzr is a bit hosed
[16:34] <Benathome> whenever i try and do a bzr init I get:
[16:35] <Benathome> bzr: ERROR: No such file: u'/private/tmp/test/.bzr/README': [Errno 2] No such file or directory: '/private/tmp/test/.bzr/README.477.macbook/.gft5rmx1uy.tmp'
[16:35] <Benathome> anyone got any ideas?
[16:36] <Pilky> Benathome: what version of bazaar do you have installed?
[16:39] <Benathome> Pilky: I just reinstalled the lastest version
[16:39] <Benathome> benrometsch@macbook /tmp/test $ bzr version
[16:39] <Benathome> Bazaar (bzr) 2.1.0
[16:39] <Pilky> hmm
[16:39] <Pilky> is it just in /private/tmp/test that you can't create or have you tried elsewhere?
[16:40] <Benathome> i have tried elsewhere including in my ~ dir
[16:41] <Pilky> not sure, beyond uninstalling and reinstalling
[16:41] <Benathome> I've tried that!
[16:41] <Benathome> wasn't sure what the best uninstall method was tho
[16:41] <Pilky> there's an uninstall script
[16:42] <Benathome> ah ok
[16:42] <Benathome> where abouts?
[16:42] <Pilky> https://launchpad.net/bazaar-mac-uninstaller
[16:42] <Benathome> great thanks
[16:42] <Pilky> I would maybe try uninstalling
[16:42] <Benathome> lol - dont say I need bzr to uninstall it :S?
[16:43] <Pilky> then try installing 2.0.4
[16:43] <Benathome> ok
[16:43] <Pilky> http://bazaar.launchpad.net/%7Ebzr/bazaar-mac-uninstaller/trunk/annotate/head%3A/uninstall-bazaar.py
[16:43] <Benathome> yeah thanks I just downloaded that
[16:44] <Pilky> you could just copy & paste that into a text file
[16:44] <Benathome> but I get benrometsch@macbook ~/Downloads $ sudo python uninstall-bazaar.py
[16:44] <Benathome> ls: /Library/Receipts/boms/org.pythonmac.bazaar*: No such file or directory
[16:44] <Benathome> should it be running python 2.5 or 2.6?
[16:44] <Pilky> did you install via the the disk image?
[16:44] <Benathome> yeah
[16:45] <Benathome> I had installed it via pip and homebrew
[16:45] <Benathome> it was all working fine
[16:45] <Benathome> but suddenly stopped working
[16:45] <Pilky> depends if you are on 10.5 or 10.6
[16:45] <Benathome> I tried uninstalling it from pip and homebrew
[16:45] <Benathome> 10.6
[16:45] <Pilky> I think on 10.6 bzr runs 64 bit so uses python 2.6
[16:46] <Benathome> right ok
[16:46] <Benathome> that uninstaller is looking at 2.5
[16:48] <Benathome> well I ran that script, installed 2.0.4 and now I get
[16:48] <Benathome> type object 'Merger' has no attribute 'hooks'
[16:48] <Benathome> Unable to load plugin 'news_merge' from '/Library/Python/2.6/site-packages/bzrlib/plugins'
[16:48] <Benathome> something very not right :(
[16:50] <Pilky> check in /Library/Python/2.6/site-packages/bzrlib/plugins
[16:50] <Pilky> see if there is a plugin news_merge, and if so moved it to your desktop and try again
[16:51] <Benathome> ok I rmd bzrlib
[16:51] <Benathome> reinstalled 2.0.4
[16:51] <Benathome> and doing an init still gives mebzr: ERROR: No such file: u'/Users/benrometsch/.bzr/README': [Errno 2] No such file or directory: '/Users/benrometsch/.bzr/README.644.macbook/.wkx6ei3uci.tmp'
[16:52] <Pilky> ok, well then I'm stumped as well, might have to ask one of the more experienced users or the devs
[16:52] <Benathome> ok thanks for your help
[16:52] <Benathome> googling it gives me nothing :(
[17:01] <Benathome> OK well, updating the hostname on my machine fixed it!
[17:01] <Benathome> very very odd
[17:17] <jml> jelmer, hi
[17:17] <jml> jelmer, I'm with the Twisted guys and they're interested in bzr-svn
[19:49] <lifeless> moin
[19:54] <mwhudson> jelmer: would https://code.edge.launchpad.net/~vcs-imports/distcc/trunk perhaps be fixed by having the git code imports not bother creating the bzr working tree?
[20:10] <jelmer> mwhudson, it's fixed in current bzr-svn
[20:10] <jelmer> mwhudson, that just hasn't been rolled out to lp yet
[20:11] <mwhudson> jelmer: ok
[21:30] <meoblast001> lifeless: you around?
[21:30] <lifeless> yes
[21:31] <meoblast001> ok, i was talking to you the other day about plugins, and felt it would be best to ask my question to you as you already know what i'm doing
[21:31] <meoblast001> suppose i have def phook(result):, where is documentation of what would be passed as result
[21:31] <meoblast001> and what it contains
[21:32] <meoblast001> for example, if this is a post_change_branch_tip hook
[21:32] <lifeless> bzr help hooks | less   /branch_top
[21:32] <lifeless> sorry
[21:32] <lifeless>  /branch_tip
[21:32] <lifeless> the docs say what its passed
[21:32] <meoblast001>  /branch_tip: No such file or directory
[21:33] <lifeless> you can use pydoc THING to get the docs on a specific type that is mentioned
[21:33] <lifeless> the /branch_tip is a search within the less
[21:33] <meoblast001> yes, i'm doing bzr help hooks | less /branch_tip
[21:33] <lifeless> don't put /branch_tip in the command line
[21:33] <lifeless> type it after hitting enter
[21:34] <meoblast001> yes, but it doesn't say what information is passed to the hook
[21:35] <lifeless> 'post_change_branch_tip is called with a
[21:35] <lifeless> bzrlib.branch.ChangeBranchTipParams.'
[21:35] <lifeless> seems to say so to me
[21:35] <meoblast001> ah, that ChangeBranchTipParams is a data structure? or whatever it's called in Python
[21:35] <meoblast001> sorry, i'm more of the C/C++ guy
[21:35] <lifeless> pydoc bzrlib.branch.ChangeBranchTipParams
[21:35] <meoblast001> ok, thanks
[21:36] <meoblast001> hm, so there is no information regarding the commit message?
[21:38] <lifeless> branch.repository.get_revision(new_revid).message
[21:38] <meoblast001> ah, ok
[22:28] <meoblast001> lifeless: now that i wrote my bot server, time to write that plugin ;)
[22:41] <james_w> "creating new compressed block on-the-fly"
[22:42] <james_w> is that useful information for anyone?
[22:46] <Peng> It's useful information for...the developers. Maybe. Once.
[22:47] <lifeless> james_w: yes, but not always.
[22:47] <lifeless> it should be -D something hidden
[22:48] <james_w> I find it rather overwhelms the messages that I normally care about
[22:50] <meoblast001> lifeless: is new_revno an integer (i understand typing in Python is not as strict as in C)
[22:51] <lifeless> meoblast001: I think so
[22:52] <meoblast001> ok, thanks
[23:13] <meoblast001> lifeless: i'm getting the feeling Python is going to mess this all up for me
[23:13] <meoblast001> :/
[23:20] <jelmer> 'evening
[23:55] <mkanat> Okay, so I go back to an old version using "bzr revert" to apply a patch. Now how do I tell bzr to update to HEAD with my patch applied, so that I can see bzr's conflicts instead of "patch"'s conflicts?
[23:56] <mwhudson> mkanat: 'bzr revert' ?
[23:56] <mwhudson> with no args
[23:56] <mkanat> mwhudson: Which deletes my patch?
[23:56] <mwhudson> oh right durr
[23:57] <mkanat> I expected a -r argument on up, but there isn't one.
[23:57] <mwhudson> i think there might be in bzr.dev actually
[23:57] <lifeless> meoblast001: how so?
[23:57] <meoblast001> lifeless: i want to send a 4 byte integer over the network
[23:57] <lifeless> mkanat: rather than going back with revert; do this:
[23:57] <lifeless> mkanat: bzr branch . ../patch
[23:57] <meoblast001> after a lovely talk with the people in #python, it looks like it will be painful
[23:57] <lifeless> cd ../patch
[23:58] <lifeless> bzr uncommit -r <when patch was made>; bzr revert
[23:58] <lifeless> apply the patch
[23:58] <lifeless> bzr commit --author "Who wrote the patch <Whowrote@thepatch.com>"
[23:58] <lifeless> mkanat: then you have a commit that represents the ptch,and can merge it as normal. And bzr knows who wrote it.
[23:58] <mkanat> lifeless: Ah, thank you.
[23:58] <lifeless> I should make a command to do this for you
[23:59] <lifeless> give it a patch file, a rev spec, and it would import, set author, and pending merge.
[23:59] <mkanat> That'd be nice.