=== asak_ is now known as asak
lifelesspickscrape: what format branch are you using ?00:19
lifelessmwhudson: actually, its quite easy to beat that :)00:19
pickscrapelifeless: default. Branch format strikes me as being a quite scary thing to mess with (coming from an svn/svk background here).00:23
Odd_Blokepickscrape: What version of bzr are you using?00:25
lifelesspickscrape: bzr info will tell you00:34
lifelesspickscrape: I want to know if it says pack-something00:34
lifelesspickscrape: if it does, pushing over sftp rather than bzr+ssh will likely be much faster, for big pushes.,00:35
lifelessjam: ping00:42
pickscrapelifeless: Knit repository format 100:46
pickscrapeI was actually using sftp before I tried bzr+ssh. It was running slowly too.00:47
pickscrapePushing locally on the server is going much quicker though (obviously)00:47
lifelessyou should upgrade to packs00:52
lifeless_much_ faster00:52
=== kiko-afk is now known as kiko-zzz
lifelesslooking for review: http://bundlebuggy.aaronbentley.com/request/%3C1202953186.6790.187.camel@lifeless-64%3E01:42
lifelessabentley: I have a use case to cherry pick against two branches simultaneously :)01:42
abentleylifeless: err?02:25
ubotuNew bug: #191729 in bzr-svn "Initial svn+http repository not remembered" [Undecided,New] https://launchpad.net/bugs/19172902:35
lifelessabentley: 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 review02:39
abentleyI think the best you can do is merge one into the other and then generate a merge directive against that.02:41
abentleyI'm willing to consider the possibility, however slight, that this is not an ideal workflow for some people.02:42
lifelessnormally I would stack them that way02:42
lifelessthis was unplanned02:42
abentleyI'm not sure whether the notion of cherrypicks can be naturally extended to multiple bases.02:44
lifelessso given A,B ->C02:44
lifelessI want a cherrypick of C to have the unique lines added to C but not added to A or B02:45
lifelessclearly it won't apply cleanly to just A, if I alter what B added in C, and vice verca.02:45
abentleyYeah, I think I understand what you want.  I'm not sure what that would require for patch generation or merge application.02:47
* igc food02:55
abentleylifeless: I think the technique used to do cherrypicks with knit and LCA merge could be extended to multiple bases.02:55
lifelessthe vim packaging folk really don't like 'Just Works'03:08
ubotuNew bug: #191731 in bzr-svn "Memory problems prevent branch of large svn repositories" [Undecided,New] https://launchpad.net/bugs/19173103:21
javamaniacsomeone knows an equivalent to "hg incoming" en bzr?03:24
Pengjavamaniac: bzr missing.03:25
Pengjavamaniac: It does both incoming and outgoing. See "bzr help missing" for args to only show one of them.03:25
javamaniacok, let's see03:25
Pengjavamaniac: 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:26
javamaniacPeng, 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:31
bob2bzr diff branch_path03:33
mwhudsonbzr diff -r ancestor:branchpath is often more what you want03:38
=== maw is now known as mw
pickscrapeSorry, wrong window :)03:43
lifelessok, I need to do some more upgrade infrastructure04:49
=== asac_ is now known as asac
=== arcsinx is now known as arctanx
spivBzrDir.find_branches seems to eat a lot of memory.  (I've noticed this with bzr multi-pull and now the bzr-avahi plugin)05:44
jameshspiv: I used to have my own version of it in bzr-avahi05:50
jameshby using code from bzrlib, it is magically someone else's problem05:50
spivjamesh: :)05:50
spivI should play with heapy or similar and find out where the memory is going.05:50
=== jrydberg__ is now known as jrydberg
vilapoolie2, poolie__ : hi. It looks like bzr-1.rc1.tar.gz and bzr-1.2 branch do not match07:47
poolie__i think it was rejected07:48
poolie__i'll check07:48
poolie__i'm trying to fix bug 189915 at the moment07:48
vilapoolie__: kthks07:48
ubotuLaunchpad bug 189915 in bzr "bzr 1.1 dapper PPA debs FTBFS" [Critical,Confirmed] https://launchpad.net/bugs/18991507:48
jmlpoolie__: you may find this site amusing: http://www.freerice.com08:05
jmlman, that reads like spam08:05
poolie__rice rice baby08:06
poolie__refined carbs/handouts/banner adds/bizarro wristband campaigns/etc08:08
poolie__   1. hoary means:08:09
poolie__   2. urgent08:09
poolie__   3. singsong08:09
poolie__   4. gruesome08:09
poolie__   5. ancient08:09
jamesh6. Linux Distribution08:09
PengShould patches that haven't been merged yet move their NEWS entries out of the 1.2 section?09:58
=== weigon__ is now known as weigo
=== weigo is now known as weigon
PengOh no! I typoed a commit message! :(10:28
Parker-then uncommit :P10:29
PengIt's a few commits old.10:30
PengI never noticed, so perhaps no one else will, eh?10:30
Parker-heh... yep...10:31
Parker-and tyops aer cmmoon10:31
=== AnMaster_ is now known as AnMaster
* mvo_ sends a valentines card to bzr shelve/unshelve for being so nice11:21
pygihey folks11:29
pygihow would I resolve a tag conflict?11:29
ignashow 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:53
jelmerignas: bzr issing11:55
datoignas: missing, passing --mine-only or --theirs-only as appropriate11:55
ignasbut it has no "-d" parameter it seems :/11:58
pygithis tags stuff seems so weird ...11:59
ubotuNew bug: #191813 in bzr-webserve "Inventory: Pressing a binary file show binary data" [Undecided,New] https://launchpad.net/bugs/19181312:30
vilaubotu: Don't Do That Then ! :)12:34
=== kiko-zzz is now known as kiko
=== mvo__ is now known as mvo
=== mvo_ is now known as mvo
=== statik` is now known as statik
=== mrevell is now known as mrevell-lunch
=== kiko is now known as kiko-fud
=== maw is now known as mw
cr3thanks folks for having created that bzr package for dapper :)16:15
=== mrevell-lunch is now known as mrevell
=== kiko-fud is now known as kiko
ubotuNew bug: #191917 in bzr "bzr cvsps-import crashes with assertion error" [Undecided,New] https://launchpad.net/bugs/19191719:15
=== cr3_ is now known as cr3
=== cr3_ is now known as cr3
garyvdmHi - I'm trying to use bzr-svn for the first time. I'm geting this error: http://pastebin.org/1962720:48
garyvdmWhat am I doing wrong?20:48
jelmergaryvdm: use "bzr svn-push" if you're trying to create a new branch20:49
jelmerWhoops, looks like you're not trying to do that...20:49
garyvdmTrying to create a local branch20:50
garyvdmNot one on svn :-)20:50
garyvdm~/meld = init-repo --subversion20:50
jelmerthen you are trying to create a new branch in subversion20:51
jelmerif you want to make a local copy, use init-repo --rich-root-pack20:51
garyvdmOh - ok20:51
jelmerinit-repo --subversion creates a subversion repository20:51
garyvdmThanks - its working now.20:52
james_wpoolie__: hi. I'm not sure if you did the upload to the PPA, but it FTBFS again.21:56
james_wpoolie__: from a quick glance it seems that you need to Build-Depend on python-all instead of python.21:56
james_wpoolie__: 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_wpoolie__: if you already know all of this, or it wasn't you then my apologies.21:57
=== zmanuel is now known as z-man
poolie__james_w, thanks, i was aware it had probably failed22:41
ubotuLaunchpad 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 dapper22:41
lamontpoolie__: exactly22:42
datothere was a patch for dapper by jeff licquia22:42
james_wis python-support?22:42
datobut it was so minimal when I read it that I don't know if it was correct22:42
datoyou *could* try to build the sarge backport22:42
poolie__there is a patch on that bug from lamont22:42
poolie__so can we switch it to python-support on all distros, or do they need to remain different?22:43
james_wyeah, 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:44
lifelesspoolie__: are you using the bzr-packaging-teams packaging ?22:45
poolie__I was trying to just uupdate from that22:45
lifelesspoolie__: if you extended my packages you are22:45
poolie__but i have tried to use the same packaging across all distros, which is the problem22:46
poolie__do they have different branches for each distro?22:46
=== poolie__ is now known as poolie
lifelessdistro release rather22:46
james_wthere is an etch-backports branch I think, but it doesn't have the changes you need.22:46
lifelesssid & hardy are the same22:46
lifelessand dapper and etch22:46
lifelessI used the patch from the list to convert the hardy branch down to dapper22:47
datodapper != etch22:47
lifelessdato: hmm, true; I'd actually have to go check my branches22:47
lifelesspoolie: point is - yes every distro code name had its own branch22:47
lifelesspoolie: where the deps and build stuff was the same I pulled between them, when it wasn't I merged changes.22:48
datopersonally I think not using nor pycentral nor pysupport would be best for dapper22:48
lifelesstoo many negatives22:49
poolieusing neither you mean22:49
james_wCouldn't it just be built for the default python in dapper?22:49
lifelessjames_w: dapper is pre the modern python packaging stuff entirely22:50
james_wyeah, but I mean just don't even try and support more than one python.22:50
datoso you just build it the old way22:50
datoand it's much easier than sarge because python points to 2.4 and not 2.3, and docutils is already at 4.x22:51
dato0.4 I mean22:51
lifelesspoolie: spiv: ping23:19
spivigc: file:///usr/share/doc/python2.4/html/lib/standard-encodings.html23:19
spivlifeless: pong23:20
igcthanks spiv23:20
lifelesscan we talk about the network protocol; I've sent mail but I have to assume there is some confusion reigning23:20
spivlifeless: sure23:21
spivlifeless: it looks like I was unclear in my mail23:21
lifelessI read 'lets not do X because Y, where Y is unrelated'23:21
spivlifeless: by "interruption", I mean interruption by the sender, not the receiver.23:22
spivlifeless: i.e. "here's a body... *streams* -- Oops!  I just exploded, and am aborting the stream."23:23
spivlifeless: it's still all half-duplex.23:24
lifelessspiv: which is precisely why I suggested have the tuple stuff exclusively after the body23:24
spivlifeless: but requests have the same issue.23:24
spivlifeless: 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:24
lifelessspiv: right, symmetry. do it the same way for both directions.23:25
spivlifeless: 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:25
lifelessspiv: this is true23:28
lifelessspiv: so noting that; the situation is not identical because the server doesn't have state but neither does the client23:32
lifelessspiv: also the client may well be unable to finish the stream without additional structured data.23:32
lifelessspiv: so perhaps saying entity: [*TUPLE|BYTES)+]23:32
spivlifeless: you mean rather a body being just a series of byte chunks, make it optionally more structured?23:34
lifelessno, I mean making the entire message a series of things23:35
lifelesswhere each thing is either a tuple23:35
lifelessor a bytestream23:35
spivThat sounds like an over-generalisation to me.23:35
lifelessbut you are proposing23:36
lifelessTUPLE [BYTES, TUPLE]23:36
lifelessor something like that23:36
spivI'm worried that sort of free-form structure would require more complexity than we need...23:36
spivSomething like that.  Basically it's still ARGS [BODY], with the possibility to abort the BODY.23:38
lifelesswhich means the body is delimited23:38
lifelessand you wanted to add error details when its aborted23:39
spivAnd so far the ARGS + BODY idiom has fit pretty well with what we've wanted to do.23:39
lifelesswhich means another ARGS23:39
spivRight, 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:39
pooliei can't parse23:40
poolie<lifeless> spiv: so noting that; the situation is not identical because the server doesn't have state but neither does the client23:40
spiv[(TUPLE|BYTES)+] basically suggests to me a whole extra layer.23:40
poolieand i'm not sure how that would map into the api23:40
poolieat the moment, it is: after getting the header, you can read the bytes, but that23:41
poolieand each call to do so can either 1-return bytes 2-return eof 3-raise an erro23:41
pooliethis seems reasonable for both client and server23:41
pooliei guess i can see how the more general structure would work23:42
poolieallowing the receiver to say, stream some bytes, now read a tuple, etcr23:42
lifelessI don't seee TUPLE [BYTES[TUPLE]] as being any harder than (TUPLE|BYTES)+23:43
pooliei guess we could have messages saying, um23:45
poolieor message types23:45
spivWell, 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:45
pooliestart of message, parameters, bytes, error, end of message23:46
spivAdding 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:47
poolieif 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 bytes23:48
spivpoolie: we already have "start of message, parameters, bytes, error, end of message", we call them requests ;)23:48
poolieso i think robert is saying23:51
pooliewhy not make that ordering a convention rather than a requirement23:52
poolieso that the api can possibly send more parameters after the body, or some such23:52
poolieand i guess it'd be an error if the receiver was not expecting it23:52
spivI 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:52
pooliei share that uncertainty23:53
spivAnd degrees of freedom don't come for free, so my inclination is to say YAGNI.23:53
pooliehere is one case, which has an analog in http23:53
pooliewe want to send the contents of a file, and afterwards send its hash for verification23:54
pooliethe sender wants to compute the hash as it's streaming the file23:54
poolieit 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 steram23:55
pooliethis is a case where the receiver might reasonably read the stream, then ask to read more parameters23:57
spivThat's true, but I still wonder how common it really is?23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!