[00:19] <lifeless> pickscrape: what format branch are you using ?
[00:19] <lifeless> mwhudson: actually, its quite easy to beat that :)
[00:23] <pickscrape> lifeless: default. Branch format strikes me as being a quite scary thing to mess with (coming from an svn/svk background here).
[00:25] <Odd_Bloke> pickscrape: What version of bzr are you using?
[00:26] <pickscrape> 1.1.0
[00:34] <lifeless> pickscrape: bzr info will tell you
[00:34] <lifeless> pickscrape: I want to know if it says pack-something
[00:35] <lifeless> pickscrape: if it does, pushing over sftp rather than bzr+ssh will likely be much faster, for big pushes.,
[00:42] <lifeless> jam: ping
[00:46] <pickscrape> lifeless: Knit repository format 1
[00:47] <pickscrape> I was actually using sftp before I tried bzr+ssh. It was running slowly too.
[00:47] <pickscrape> Pushing locally on the server is going much quicker though (obviously)
[00:52] <lifeless> you should upgrade to packs
[00:52] <lifeless> _much_ faster
[01:42] <lifeless> looking for review: http://bundlebuggy.aaronbentley.com/request/%3C1202953186.6790.187.camel@lifeless-64%3E
[01:42] <lifeless> abentley: I have a use case to cherry pick against two branches simultaneously :)
[02:25] <abentley> lifeless: err?
[02:35] <ubotu> New bug: #191729 in bzr-svn "Initial svn+http repository not remembered" [Undecided,New] https://launchpad.net/bugs/191729
[02:39] <lifeless> abentley: I have two branches which have pending merge requests on bb; I have a third branch based on both, which I'd like to send in for separate review
[02:41] <abentley> I think the best you can do is merge one into the other and then generate a merge directive against that.
[02:42] <abentley> I'm willing to consider the possibility, however slight, that this is not an ideal workflow for some people.
[02:42] <lifeless> ;)
[02:42] <lifeless> normally I would stack them that way
[02:42] <lifeless> this was unplanned
[02:44] <abentley> I'm not sure whether the notion of cherrypicks can be naturally extended to multiple bases.
[02:44] <lifeless> so given A,B ->C
[02:45] <lifeless> I want a cherrypick of C to have the unique lines added to C but not added to A or B
[02:45] <lifeless> clearly it won't apply cleanly to just A, if I alter what B added in C, and vice verca.
[02:47] <abentley> Yeah, I think I understand what you want.  I'm not sure what that would require for patch generation or merge application.
[02:55]  * igc food
[02:55] <abentley> lifeless: I think the technique used to do cherrypicks with knit and LCA merge could be extended to multiple bases.
[03:08] <lifeless> wow
[03:08] <lifeless> the vim packaging folk really don't like 'Just Works'
[03:08] <lifeless> http://pkg-vim.alioth.debian.org/vim-policy.html/
[03:21] <ubotu> New bug: #191731 in bzr-svn "Memory problems prevent branch of large svn repositories" [Undecided,New] https://launchpad.net/bugs/191731
[03:24] <javamaniac> Hi
[03:24] <javamaniac> someone knows an equivalent to "hg incoming" en bzr?
[03:24] <javamaniac> in*
[03:25] <Peng> javamaniac: bzr missing.
[03:25] <Peng> javamaniac: It does both incoming and outgoing. See "bzr help missing" for args to only show one of them.
[03:25] <javamaniac> ok, let's see
[03:26] <Peng> javamaniac: If you're planning to pull, you can also do "bzr pull -v" to pull new csets and list them at the same time.
[03:31] <javamaniac> Peng, in mercurial , there's a -p to show the patch of those "missing" changesets, I can't see something like that in bzr, How can I achieve  that?
[03:33] <bob2> bzr diff branch_path
[03:38] <mwhudson> bzr diff -r ancestor:branchpath is often more what you want
[03:43] <pickscrape> n
[03:43] <pickscrape> Sorry, wrong window :)
[04:49] <lifeless> ok, I need to do some more upgrade infrastructure
[04:49] <lifeless> tomorrow
[05:44] <spiv> BzrDir.find_branches seems to eat a lot of memory.  (I've noticed this with bzr multi-pull and now the bzr-avahi plugin)
[05:50] <jamesh> spiv: I used to have my own version of it in bzr-avahi
[05:50] <jamesh> by using code from bzrlib, it is magically someone else's problem
[05:50] <spiv> jamesh: :)
[05:50] <spiv> I should play with heapy or similar and find out where the memory is going.
[07:47] <vila> poolie2, poolie__ : hi. It looks like bzr-1.rc1.tar.gz and bzr-1.2 branch do not match
[07:48] <poolie__> i think it was rejected
[07:48] <poolie__> i'll check
[07:48] <poolie__> i'm trying to fix bug 189915 at the moment
[07:48] <vila> poolie__: kthks
[07:48] <ubotu> Launchpad bug 189915 in bzr "bzr 1.1 dapper PPA debs FTBFS" [Critical,Confirmed] https://launchpad.net/bugs/189915
[08:05] <jml> poolie__: you may find this site amusing: http://www.freerice.com
[08:05] <jml> man, that reads like spam
[08:06] <poolie__> rice rice baby
[08:07] <poolie__> hm
[08:08] <poolie__> refined carbs/handouts/banner adds/bizarro wristband campaigns/etc
[08:09] <poolie__>    1. hoary means:
[08:09] <poolie__>    2. urgent
[08:09] <poolie__>    3. singsong
[08:09] <poolie__>    4. gruesome
[08:09] <poolie__>    5. ancient
[08:09] <jamesh> 6. Linux Distribution
[08:09] <AfC> 5
[09:58] <Peng> Should patches that haven't been merged yet move their NEWS entries out of the 1.2 section?
[10:16] <pygi> hi
[10:28] <Peng> Oh no! I typoed a commit message! :(
[10:29] <Parker-> then uncommit :P
[10:30] <Peng> It's a few commits old.
[10:30] <Peng> I never noticed, so perhaps no one else will, eh?
[10:31] <Parker-> heh... yep...
[10:31] <Parker-> and tyops aer cmmoon
[10:33] <Peng> Yeah.
[11:21]  * mvo_ sends a valentines card to bzr shelve/unshelve for being so nice
[11:29] <pygi> hey folks
[11:29] <pygi> how would I resolve a tag conflict?
[11:46] <ignas> hi
[11:53] <ignas> how do I get a changelog when comparing 2 branches? I want to get a list of changes present in one branch, but not in the other ...
[11:55] <jelmer> ignas: bzr issing
[11:55] <dato> ignas: missing, passing --mine-only or --theirs-only as appropriate
[11:55] <jelmer> *missing
[11:56] <ignas> thanks
[11:58] <ignas> but it has no "-d" parameter it seems :/
[11:59] <pygi> this tags stuff seems so weird ...
[12:10] <pygi> solved
[12:30] <ubotu> New bug: #191813 in bzr-webserve "Inventory: Pressing a binary file show binary data" [Undecided,New] https://launchpad.net/bugs/191813
[12:34] <vila> ubotu: Don't Do That Then ! :)
[16:15] <cr3> thanks folks for having created that bzr package for dapper :)
[19:15] <ubotu> New bug: #191917 in bzr "bzr cvsps-import crashes with assertion error" [Undecided,New] https://launchpad.net/bugs/191917
[20:48] <garyvdm> Hi - I'm trying to use bzr-svn for the first time. I'm geting this error: http://pastebin.org/19627
[20:48] <garyvdm> What am I doing wrong?
[20:49] <jelmer> garyvdm: use "bzr svn-push" if you're trying to create a new branch
[20:49] <garyvdm> Ok
[20:49] <jelmer> Whoops, looks like you're not trying to do that...
[20:50] <garyvdm> Trying to create a local branch
[20:50] <garyvdm> Not one on svn :-)
[20:50] <garyvdm> ~/meld = init-repo --subversion
[20:51] <jelmer> then you are trying to create a new branch in subversion
[20:51] <jelmer> if you want to make a local copy, use init-repo --rich-root-pack
[20:51] <garyvdm> Oh - ok
[20:51] <jelmer> init-repo --subversion creates a subversion repository
[20:52] <garyvdm> Thanks - its working now.
[21:56] <james_w> poolie__: hi. I'm not sure if you did the upload to the PPA, but it FTBFS again.
[21:56] <james_w> poolie__: from a quick glance it seems that you need to Build-Depend on python-all instead of python.
[21:57] <james_w> poolie__: also, it seems that you may be using python-support, rather than python-central. If you have changed this then you should be aware that last time I looked the plugins and the core had to use the same system otherwise the plugins weren't registered.
[21:57] <james_w> poolie__: if you already know all of this, or it wasn't you then my apologies.
[22:13] <igc> morning
[22:41] <poolie__> james_w, thanks, i was aware it had probably failed
[22:41] <poolie__> https://bugs.edge.launchpad.net/bzr/+bug/189915
[22:41] <ubotu> Launchpad bug 189915 in bzr "bzr 1.1 dapper PPA debs FTBFS" [Critical,In progress]
[22:41] <poolie__> lamont says that python-central isn't in dapper
[22:42] <lamont> poolie__: exactly
[22:42] <dato> there was a patch for dapper by jeff licquia
[22:42] <james_w> is python-support?
[22:42] <dato> but it was so minimal when I read it that I don't know if it was correct
[22:42] <dato> you *could* try to build the sarge backport
[22:42] <poolie__> there is a patch on that bug from lamont
[22:43] <poolie__> so can we switch it to python-support on all distros, or do they need to remain different?
[22:44] <james_w> yeah, you could do that. However all plugins would have to be changed at the same time.
[22:44] <james_w> (all packages of plugins I mean)
[22:45] <lifeless> poolie__: are you using the bzr-packaging-teams packaging ?
[22:45] <poolie__> I was trying to just uupdate from that
[22:45] <lifeless> poolie__: if you extended my packages you are
[22:46] <poolie__> but i have tried to use the same packaging across all distros, which is the problem
[22:46] <poolie__> do they have different branches for each distro?
[22:46] <lifeless> yes
[22:46] <lifeless> distro release rather
[22:46] <james_w> there is an etch-backports branch I think, but it doesn't have the changes you need.
[22:46] <lifeless> sid & hardy are the same
[22:46] <lifeless> and dapper and etch
[22:47] <lifeless> I used the patch from the list to convert the hardy branch down to dapper
[22:47] <dato> dapper != etch
[22:47] <lifeless> dato: hmm, true; I'd actually have to go check my branches
[22:47] <lifeless> poolie: point is - yes every distro code name had its own branch
[22:48] <lifeless> poolie: where the deps and build stuff was the same I pulled between them, when it wasn't I merged changes.
[22:48] <dato> personally I think not using nor pycentral nor pysupport would be best for dapper
[22:49] <lifeless> too many negatives
[22:49] <poolie> using neither you mean
[22:49] <poolie> ok
[22:49] <james_w> Couldn't it just be built for the default python in dapper?
[22:50] <lifeless> james_w: dapper is pre the modern python packaging stuff entirely
[22:50] <dato> right
[22:50] <james_w> yeah, but I mean just don't even try and support more than one python.
[22:50] <dato> so you just build it the old way
[22:51] <dato> and it's much easier than sarge because python points to 2.4 and not 2.3, and docutils is already at 4.x
[22:51] <dato> 0.4 I mean
[23:19] <lifeless> poolie: spiv: ping
[23:19] <spiv> igc: file:///usr/share/doc/python2.4/html/lib/standard-encodings.html
[23:20] <spiv> lifeless: pong
[23:20] <igc> thanks spiv
[23:20] <lifeless> can we talk about the network protocol; I've sent mail but I have to assume there is some confusion reigning
[23:21] <spiv> lifeless: sure
[23:21] <spiv> lifeless: it looks like I was unclear in my mail
[23:21] <lifeless> I read 'lets not do X because Y, where Y is unrelated'
[23:22] <spiv> lifeless: by "interruption", I mean interruption by the sender, not the receiver.
[23:23] <spiv> lifeless: i.e. "here's a body... *streams* -- Oops!  I just exploded, and am aborting the stream."
[23:24] <spiv> lifeless: it's still all half-duplex.
[23:24] <lifeless> spiv: which is precisely why I suggested have the tuple stuff exclusively after the body
[23:24] <spiv> lifeless: but requests have the same issue.
[23:24] <spiv> lifeless: they can also stream bodies, and should have a way to explicitly signal "oops, that's not a complete stream because I just blew up."
[23:25] <lifeless> spiv: right, symmetry. do it the same way for both directions.
[23:25] <spiv> lifeless: but requests can't have the body come before the verb, because that would force the server to buffer, because it wouldn't know what the body was for.
[23:28] <lifeless> spiv: this is true
[23:32] <lifeless> spiv: so noting that; the situation is not identical because the server doesn't have state but neither does the client
[23:32] <lifeless> spiv: also the client may well be unable to finish the stream without additional structured data.
[23:32] <lifeless> spiv: so perhaps saying entity: [*TUPLE|BYTES)+]
[23:34] <spiv> lifeless: you mean rather a body being just a series of byte chunks, make it optionally more structured?
[23:35] <lifeless> no, I mean making the entire message a series of things
[23:35] <lifeless> where each thing is either a tuple
[23:35] <lifeless> or a bytestream
[23:35] <spiv> That sounds like an over-generalisation to me.
[23:36] <lifeless> perhaps
[23:36] <lifeless> but you are proposing
[23:36] <lifeless> TUPLE [BYTES, TUPLE]
[23:36] <lifeless> already
[23:36] <lifeless> or something like that
[23:36] <spiv> I'm worried that sort of free-form structure would require more complexity than we need...
[23:38] <spiv> Something like that.  Basically it's still ARGS [BODY], with the possibility to abort the BODY.
[23:38] <lifeless> which means the body is delimited
[23:39] <lifeless> and you wanted to add error details when its aborted
[23:39] <spiv> And so far the ARGS + BODY idiom has fit pretty well with what we've wanted to do.
[23:39] <lifeless> which means another ARGS
[23:39] <lifeless> :)
[23:39] <spiv> Right, those are some of the details.  I'm just saying the protocol still conceptually is directly related to what the code does and expects.
[23:40] <poolie> i can't parse
 spiv: so noting that; the situation is not identical because the server doesn't have state but neither does the client
[23:40] <spiv> [(TUPLE|BYTES)+] basically suggests to me a whole extra layer.
[23:40] <poolie> and i'm not sure how that would map into the api
[23:41] <poolie> at the moment, it is: after getting the header, you can read the bytes, but that
[23:41] <poolie> and each call to do so can either 1-return bytes 2-return eof 3-raise an erro
[23:41] <poolie> r
[23:41] <poolie> this seems reasonable for both client and server
[23:41] <poolie> hm
[23:42] <poolie> i guess i can see how the more general structure would work
[23:42] <poolie> allowing the receiver to say, stream some bytes, now read a tuple, etcr
[23:43] <lifeless> I don't seee TUPLE [BYTES[TUPLE]] as being any harder than (TUPLE|BYTES)+
[23:45] <poolie> i guess we could have messages saying, um
[23:45] <poolie> or message types
[23:45] <spiv> Well, we can always use streamed bodies for complex structured data like that.  I don't know that that's a common enough case to make it be the overall protocol.
[23:46] <poolie> start of message, parameters, bytes, error, end of message
[23:47] <spiv> Adding flexibility to the protocol has the downside that now you expect the request handlers and response handlers to be able to cope with that flexibility.  *Maybe* we can hide most of that in the default base class for request handlers (although we don't really have such a thing for response handlers), but I'm not sure.
[23:48] <poolie> if we had the messages marked that way, and the receiver knew what they expected, then it could be an error for them to get parameters when they expected bytes
[23:48] <spiv> poolie: we already have "start of message, parameters, bytes, error, end of message", we call them requests ;)
[23:51] <poolie> so i think robert is saying
[23:52] <poolie> why not make that ordering a convention rather than a requirement
[23:52] <poolie> so that the api can possibly send more parameters after the body, or some such
[23:52] <poolie> and i guess it'd be an error if the receiver was not expecting it
[23:52] <spiv> I guess because I'm not sure that we'll actually have a use for this complexity.  We can always send bencoded structures (and already do), or multiple requests.
[23:53] <poolie> i share that uncertainty
[23:53] <spiv> And degrees of freedom don't come for free, so my inclination is to say YAGNI.
[23:53] <poolie> here is one case, which has an analog in http
[23:54] <poolie> we want to send the contents of a file, and afterwards send its hash for verification
[23:54] <poolie> the sender wants to compute the hash as it's streaming the file
[23:55] <poolie> it would be possible for it to encode that into the stream, but that seems a bit redundant since the protocol already has markers for the byte steram
[23:57] <spiv> Hmm.
[23:57] <poolie> this is a case where the receiver might reasonably read the stream, then ask to read more parameters
[23:59] <spiv> That's true, but I still wonder how common it really is?