[00:33] <mjflick> hi, i compiled bzr but i'm getting the following error when running it, "bzrlib._static_tuple_c.StaticTuple is not a type object"
[00:33] <mjflick> any ideas what's broken here?
[00:33] <lifeless> what python ?
[00:34] <mjflick> 2.5.2
[00:36] <poolie> kind of sounds like something's out of date with your python version
[00:36] <mjflick> great
[01:01] <spiv> Hi folks.
[01:27] <poolie> hi there spiv
[02:29] <poolie> lifeless, http://people.canonical.com/~mbp/kanban/canonical-bazaar-kanban.html
[02:59] <echo-area> spiv, vila: I'm sorry I was busy doing other things these days so I didn't follow up spiv's bug report and didn't work on the document improvement of types of conflicts yet.  I'm still busy now, but I'll return to this later.  Apologize.
[03:59] <AfC> Is there no way to engineer out the "updating git map" step? It's going to take half an hour!
[04:02] <AfC> then "fatal: The remote end hung up unexpectedly"
[04:02] <poolie> :/
[04:02] <AfC> then, we start again at 0/19738
[04:02] <poolie> jelmer would know best, and he's likely asleep?
[04:02] <AfC> bloody hell
[04:02] <poolie> file a bug?
[04:02] <AfC> yeah
[04:02] <AfC> poolie: I guess I've kinda got tired of hassling Jelmer with bugs about bzr-git
[04:03] <mwhudson> i bet you haven't done it nearly as much as me
[04:03] <AfC> I never seem to be able to get it to work :(
[04:03] <poolie> i don't think he feels hassledh
[04:03] <poolie> and they do seem to get closed
[04:05] <AfC> poolie: filed, https://bugs.launchpad.net/bzr/+bug/753155
[04:08] <poolie> thanks
[06:13] <poolie> ok, SRUs here i come
[07:15] <poolie> OK, sru for bug 707075 proposed; let's see
[07:17] <lifeless> thats no good
[07:18] <lifeless> 2.5 seconds for me
[07:18] <lifeless> 177 queries though
[07:18] <lifeless> which makes me sad
[07:55] <vila> lifeless: 197 queries/external actions issued in 4.01 seconds here
[07:55] <vila> hi all !
[07:56] <vila> poolie: 2.1.4 is planned for next week, are you ok to wait a bit and use bug #707075 (come one ubot5, try better) to drive the 2.1.4 SRU ?
[07:56] <vila> good bot
[07:57] <lifeless> vila: thats interesting, I wonder why
[07:57] <vila> lifeless: 177 vs 197 you mean ? I was about to ask
[07:58] <lifeless> possibly there is a memcache fragment in there we missed
[07:58] <lifeless> but it should be disabled on BugTask:+index
[08:10]  * spiv steps AFK.
[08:10] <spiv> Back in a bit.
[08:12]  * vila scratches head
[08:13] <vila> poolie: how can I check that bzr has been uploaded to maverick-proposed ? It doesn't show up in synaptic...
[08:16] <lifeless> vila: become an ubuntu archive-admin
[08:16] <lifeless> vila: you might be able to see it in the maverick +queue page
[08:17] <vila> lifeless: the intent is to test it, I hope testing is open to non-admin people
[08:17] <lifeless> once its accepted into -proposed, yes
[08:17] <vila> oh, ok, that's probably the issue then
[08:20] <maxb> https://launchpad.net/ubuntu/maverick/+queue?queue_state=1&queue_text=bzr
[08:20] <maxb> vila: ^
[08:21] <vila> maxb: you rock ;)
[08:22] <vila> >-/ http://launchpadlibrarian.net/68515880/bzr_2.2.1-0ubuntu1_2.2.4-0ubuntu1.diff.gz mentions 2.2.2-dev in the generated C files
[08:24] <vila> may be the generated content is correct but if it has been generated there but this seems really wrong
[08:25] <vila> it should be 2.2.3-dev according to my local workflow
[08:25] <vila> err, no, 2.2.4-dev of course
[08:27] <vila> ok, false alarm
[08:28] <vila> it's a local glitch, I rely on make there *but* rename the directories after releases, so the path mentioned is the one that was current the last time the file has been generated
[08:29] <vila> I should probably add 'make clean; make' somewhere to avoid this
[08:30] <vila> on the other hand, full paths should be used only when building locally for debug purposes, relative paths should be used otherwise,
[08:31] <vila> especially for releases so that the above diff will stop containing the spurious comment changes
[08:33] <vila> I thought we had a bug for that but all I can find is bug #336933 which is only tangentially related
[08:38] <maxb> vila: I would like that. I suppose we need to either fix pyrexc or apply sed
[08:41] <vila> maxb: yup, I vaguely remember looking at that loong ago but don't remember ever finding a solution (didn't try sed though)
[08:41] <vila> but injecting sed between generation and compilation in build_extension may be tricky
[08:41] <fullermd> I recall doing a bunch of sed'ery in my (unsuccessful) attempt to figure out why they were blowing up a couple years back.
[08:43] <vila> and Cython may proceed differently, but anyway, it may be worth another try
[08:43] <fullermd> Last I checked, cython just flat didn't work, so that's easy to ignore  ;)
[08:43] <vila> hehe
[08:59] <poolie> hi spiv, vila, jam, jelmer
[08:59] <jelmer> hey poolie
[08:59] <vila> poolie: hey
[09:00] <poolie> hi there
[09:00] <poolie> iirc we're going to a have a standup call now?
[09:01] <spiv> poolie: yes
[09:02] <jam> hi poolie, what method?
[09:03]  * spiv is on mumble
[09:03] <poolie> mumble?
[09:04] <poolie> it apparently wants to be reinitialized for natty
[09:04] <jam> apparently we upset vila
[09:04] <poolie> :)
[09:19] <vila> poolie, jam, jelmer, spiv : Gee, I lack caffeine: lp says 2011-*05*-12 and that's right unless someone insists about releasing 2.1.4 sooner, next month seems fine as far as SRUs are concerned
[09:21] <poolie> hi jelmer?
[09:21] <jam> vila: not a whole lot of stuff in the 2.1 series that I can see *needs* release
[09:22] <jam> Though it is nice if we are going to do a backport to actually get it out to users.
[09:22] <vila> jam: sure, but what we want is to get 2.1 updated for lucid which is LTS, so it's more about having the SRUs running (and we need to SRU 2.2 *before* 2.1 AIUI)
[09:22] <poolie> still here?
[09:22] <jelmer> FFS
[09:22] <poolie> jelmer, that's nice
[09:22] <jam> jelmer: want to finish up in IRC
[09:22] <jam> we'll just talk about you behind your back
[09:22] <jelmer> yeah, that might be better, my mumble seems unreliable today
[09:22] <poolie> jelmer, you should send a mail about that great result
[09:22] <jelmer> jam: >-)
[09:23] <vila> jelmer: don't worry, I had to *reboot* myself ;)
[09:23] <jelmer> This week I'd like to work on finishing the bzr-svn/bzr-hg/bzr-git releases and getting them and a newer bzr deployed on LP
[09:23] <vila> \o/
[09:23] <jelmer> as well as getting the transport-segments patch finished
[09:24] <poolie> that sounds good
[09:24] <poolie> spiv's talking about getting the twisted failure patch and workaround done
[09:24] <poolie> i'll send minutes too
[09:25] <poolie> we could try using canonical asterisk conferencing next time
[09:25] <poolie> or skype
[09:25] <poolie> spiv: and the patch to upstream twisted?
[09:26] <poolie> oh, just briefly
[09:26] <poolie> because the kanban is working well i was thinking about changing what we do with bugs
[09:26] <poolie> specifically actually using fix committed/fix released to remind us to make a release
[09:27] <vila> meh, for bzr itself you mean ?
[09:27] <poolie> yes
[09:27] <vila> We stopped using fix committed to ease the RM work IIRC
[09:28] <jam> vila: and to avoid the "100 bug spam updates when a release is made"
[09:28] <vila> and I thought Fix committed was going to be deprecated anyway
[09:29] <vila> jam: hmm, yeah, *I* wouldn't mind that if I wasn't the RM as a reminder of which fixes are about to be released
[09:30] <jelmer> it should be possible to do a trivial script that marks all bugs for a milestone as fix released
[09:31] <vila> arf arf, headset delivered *just* after the online meeting, the irony :)
[09:31] <jelmer> vila: :)
[09:38] <vila> jelmer: right, truth is I'm mainly using the milestone pages to see which bugs are fixed by which release and that will still work if we use Fix Committed so I'm not violently *against* using it (I always liked the distinction between committed and released myself though I used it to distinguish between: there are a fix in *a* branch and the fix has landed in the official branch)
[09:39] <vila> but anyway, worth discussing on the list as poolie proposed
[11:54] <poolie> o/ spiv
[11:58] <jam> poolie: does feed-pqm notice that Branch A is approved but its prerequisite B is not?
[11:59] <poolie> no
[11:59] <jam> poolie: I thought so, but just checking
[12:00] <poolie> what do you think it should do?
[12:00] <poolie> arguably lp should warn you about this
[12:01] <jam> poolie: warn/not show it as submittable/ something
[12:02] <poolie> yes
[12:02] <jam> I'm reviewing Jelmer's stack, and the first I need to discuss a bit more, most of the follow ups are obviously ok
[12:02] <jam> but I don't want to mark them Approved, since it would want to be submitted
[12:02] <jam> poolie: speaking of which, I think you have 3-4 "approved but not landed" branches.
[12:03] <jelmer> jam: hi
[12:04] <jam> hey jelmer
[12:04] <jam> jelmer: questions are in https://code.launchpad.net/~jelmer/bzr/knitpackrepo/+merge/56383
[12:05] <poolie> it is not all that great at showing the whole stack
[12:06] <jam> poolie: I realize it is a little bit tricky, since prerequisite branches are off-to-the-side, since you don't set a prerequisite merge-proposal
[12:06] <jam> which is where the "is this merged" is generally tracked
[12:07] <askhl_> Hi.  I have a bzr repository with multiple branches and tags, and would like to transfer this whole structure to a project in Launchpad.  How should this be done?
[12:08] <jelmer> jam: ah, thanks
[12:08] <askhl_> (One could conceivable create series for the different tags and manually push each tag/branch as appropriate.  Is this the smartest way or is there a better way?)
[12:08] <jam> askhl_: generally you would create a new project on launchpad, then push up your primary development branch, mark it as such, then push up the rest
[12:08] <askhl_> conceivably*
[12:09] <askhl_> jam: so the rest of the branches/tags are simply pushed individually?
[12:09] <jam> askhl_: I'm not sure what you are doing with tags, but yes
[12:09] <jam> for the branches
[12:09] <askhl_> jam: the tags correspond to stable versions.  I guess they're sort of like series
[12:10] <askhl_> jam: thanks for the help
[12:12] <jam> askhl_: what are the branches then? My guess is you would just have a series branch that happens to have the individual release tags on it.
[12:12] <jam> I don't know if you need separate branches for each release tag.
[12:12] <jam> s/need/need or want/
[12:15] <spiv> jam: related bug I filed today: https://bugs.launchpad.net/launchpad/+bug/753185
[12:26] <askhl_> Say, we have this repository.  And we would like to push the branches in this repository to LP.  But when attempting to do so, it complains that "location is a repository".  Apparently the subdirectories are not quite branches that can be pushed.  How do we proceed?
[12:26] <spiv> askhl_: push the branches, not the repository.
[12:26]  * spiv -> dinner
[12:27] <askhl_> spiv: I'm in one of them (trunk) and running bzr push lp:<project>.  That's when it complains
[12:28] <askhl_> Strange.  The trunk is actually not reported to be a branch by bzr info, while the other branches are.  Maybe this is an error in svn2bzr (which has been used)?
[12:29] <askhl_> But we need trunk to be a branch (including revision history)...
[12:33] <vila> askhl_: directory has not the same meaning in bzr and svn, in bzr it's just a revision store, bzr deals with branches mainly
[12:33] <vila> askhl_: a branch can have multiple tags, each one associated with a specific revision
[12:34] <vila> askhl_: launchpad hosts only branches with some of them having aliases for convenience
[12:35] <vila> lp:bzr is a shortcut for the dev focus branch which is lp:~bzr-pqm/bzr/bzr.dev
[12:36] <vila> for project branches, the url syntax is lp:~<user>/<project>/<branch>
[12:36] <askhl_> vila: thanks
[12:37] <vila> so, if 'bzr push lp:<project>' fails, that's possibly because the dev focus is not correctly defined for <project>
[12:37] <askhl_> So right now the problem is that svn2bzr converted the trunk branch of svn to something which is not a branch in the bzr sense.  So we need to make a branch out of it (including entire revision history) and push it to LP.
[12:37] <askhl_> We managed to push one of the non-trunk svn tags (technically a branch) successfully, it's just that trunk itself is not a branch for some reason
[12:38] <vila> askhl_: well, you need a branch to start with, I'm pretty surprised that svn2bzr produced something that isn't one
[12:38] <vila> askhl_: if you do 'bzr info' in any directory, it should tell you what it thinks the directory contains
[12:39] <vila> askhl_: pastebin'ing the result may ease the dialog ;)
[12:39] <askhl_> vila: right, bzr info reports that it is a 'shared repository', whereas for the other branches it reports two lines, one stating that it is a shared repository (or part thereof), the other stating that it is a branch
[12:40] <vila> right, so a shared repository is a repository used my multiple branches (a repository can also be private to a branch)
[12:40] <fullermd> A 'branches' run may be helpful.
[12:40] <vila> so you did the first 'bzr info' at the repository level, the branches should be down the hierarchy starting there
[12:41] <vila> ha, of course, fullermd to the rescue ;)
[12:41] <vila> askhl_: try 'bzr branches' ^
[12:41] <fullermd> From the 'top level' of your conversion.
[12:42] <askhl_> Oh, there's the problem: svn2bzr has converted all the *subdirectories* of trunk into different branches
[12:42] <fullermd> jelmer: I haven't read your email yet, but just from the subject line I'm totally in favor of whatever it contains   :p
[12:42] <vila> askhl_: 'branches' is part of the bzrtools plugin (in case you got an Unknown command error)
[12:43] <askhl_> as revealed by svn branches
[12:43] <askhl_> That explains it then
[12:44] <askhl_> Thank you, vila  and fullermd
[12:45]  * fullermd goes back to lurking until vila almost solves the next problem, then jumps in to take the credit   8-}
[12:46] <vila> fullermd: for once I didn't start with http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief which may have been an error ;)
[12:48] <vila> askhl_: I'm not that familiar with svn myself, but from the various discussions here, people use bzr-svn more than svn2bzr, you may want to have a look at it
[12:49] <fullermd> I should blow an afternoon sometime trying to see if bzr-svn can be sweet-talked into running over the BSD src repo, but I have a feeling I'd spend hours just trying to tell it the repo structure.
[12:49] <fullermd> Then more hours and several times my RAM waiting for it to figure out what to do...
[12:50] <vila> askhl_: also, launchpad can import from svn so you may wan to look there too, maybe it can do the work for you ;)
[12:50] <askhl_> vila: it seems that bzr-svn is useful for using bzr as a frontend to svn repos, whereas we are converting an svn repo to bzr permanently.  I think we'll figure it out now with bzr2svn, so things should be fine! (until we get more questions of course .))
[12:50] <jelmer> askhl_: bzr-svn has a "bzr svn-import" command that has behaviour similar to svn2bzr
[12:51] <jelmer> fullermd: how weird is the repository layout?
[12:51] <vila> jelmer: it uses CVS :-D
[12:52] <fullermd> Fairly.  Ignoring stuff that's unnecessary for a generally-good-coverage import, there's still a fair spread of stuff to get...
[12:53] <fullermd> vila: ports is still CVS.  The master for src is in svn.
[12:53] <jelmer> jam: whoa, 77 entries in your sys.path?
[12:53] <fullermd> I think about trying ports again sometimes too, but I sober up real quick  :p
[12:53] <vila> :)
[12:53] <jelmer> jam: I heard people complain about a single additional entry in sys.path on Ubuntu
[12:54] <jam> jelmer: easy_install defaults to putting every installed software into a custom location
[12:54] <jam> so that you can have 2.4 and 2.5 installed, but pick which one is active
[12:54] <jam> however, Launchpadlib has *huge* dependencies
[12:55] <jam> (well, a very large dependency stack)
[12:55] <jam> which I don't want to manually install, but obviously has some severe negatives w/ easy_install
[12:55] <jelmer> jam: hey, it's nothing compared to Launchpad's dependency stack :-P
[12:55] <jam> jelmer: sure, but you can't easy_install Launchpad on Windows, either
[12:57] <jelmer> that's probably for the best :)
[13:22] <jelmer> whoa, we had *9* knit pack repository formats?
[13:27] <maxb> I count 7 _released_ ones
[13:42] <vila> jelmer: part of why bialix was talking about a zoo format :-}
[13:42] <vila> err, format zoo
[13:44] <jelmer> yeah
[15:11] <dije> Doing a checkout to my home directory from a branch at ~/bzr_scm/dot, I get the following error:
[15:11] <dije> bzr: ERROR: Failed to rename /Users/phil/Library/Preferences to /Users/phil/.bzr/checkout/limbo/new-159/Preferences: [Errno 13] Permission denied
[15:11] <dije> How can I remediate this?
[15:13] <dije> (On Mac OS X 10.5.8, Titanium PowerBook G4)
[15:14] <dije> Anybody here?
[15:15] <jelmer> dije: hi
[15:15] <dije> jelmer: hi
[15:15] <jelmer> dije: I'm here, but I'm not entirely sure what's going on there
[15:16] <dije> Nothing shows on a google search
[15:16] <jelmer> brb
[16:54] <achiang> hello, what is the preferred GUI bzr tool?
[16:54] <achiang> i guess it's just bzr-gtk?
[16:55] <james_w> qbzr is actually better these days I think
[16:56] <james_w> bzr-explorer provides a nice intergrated environment if you prefer that to the "bunch of tools" approach
[16:59] <achiang> james_w: ok
[16:59] <achiang> james_w: i need to do a rather complex operation
[17:00] <achiang> trunk is A, merged in branch B; then had to revert B (bzr merge . --revision -2..-3); then A had more changes; then I added B back in; more changes, now i need to revert B again. :-/
[17:15] <achiang> james_w: thanks for the tip on bzr explorer. i'm stumbling my way through this morass of my own making
[18:07] <LeoNerd> ARGH FSCKING REVERT
[18:07] <LeoNerd> "bzr revert" after shelve/unshelve thought it was safe to blow away my changes. It wasn't. Any chance I can get them back, or is that gone gone?
[18:08] <james_w> LeoNerd, there will be .~N~ files for each changed file
[18:09] <james_w> where N is a number >=1, use the last for each
[18:09] <LeoNerd> No.. there aren't.
[18:09] <james_w> you used --no-backup?
[18:09] <LeoNerd> Normally there are.. not immediately after shelve/unshelve
[18:09] <LeoNerd> revert believes it's reverting after a merge, so doesn't bother to keep them
[18:09] <james_w> erk
[18:10] <LeoNerd> Fortunately I happen to have the diffs in my xterm scrollback buffer, so I can reapply. Problem is, it also reverted adding a new file, for which I dno't have the original content
[18:14] <james_w> would you file a bug on the unshelve+revert thing
[18:14] <james_w> ?
[18:14] <james_w> once you are finished unpicking the fallout
[18:14] <LeoNerd> I thought there already was one
[18:14] <james_w> oh, ok
[18:14] <LeoNerd> Atleast, I've known about it for like a year now.. seen mention of it. I was presuming debian was just behind the times in not giving me a fixed one
[18:14] <LeoNerd> Was wondering if anyone knows if the 'shelve'd content is stored somewhere after unshelve, that I could get at still
[18:15] <james_w> I don't know that it is
[19:32] <philsf> I have a local versioned dir , and I want to set it up in a server. I didn't find in the site docs what is needed on the server side to use it remotely. Is a user account and ssh access enough?
[19:47] <maxb> philsf: Yes. You can then simply use bzr+ssh://host/path/to/dir URLs in bzr commands
[20:29] <philsf> maxb, so I can just rsync the whole dir, including .bzr/* to the destination?
[20:30] <maxb> It would work, though it's not the nicest way
[20:30] <maxb> Is Bazaar installed on the serve?
[20:30] <maxb> *server
[20:30] <philsf> not yet
[20:31] <maxb> You can use Bazaar using sftp://host/path/to/dir URLs without having bzr installed remotely, though the performance will not be as good as bzr+ssh
[20:34] <philsf> what's the polite way to transfer the whole branch, instead of rsyncing the whole thing?
[20:37] <maxb> bzr push remote-url-where-you-want-it
[20:39] <philsf> forgive my ignorance, what's the difference?
[20:40]  * jelmer waves
[20:40] <maxb> Not a great deal, but: 1) pushing doesn't create a working tree on the server, and 2) your local branch remembers where you pushed it to for convenience when you want to push updates
[21:04] <philsf> thanks, bye
[23:33] <AfC> How hard would it be to have Bazaar insert a \n instead of clearing the terminal line when it's printing status messages?
[23:34] <jelmer> AfC: with status messages, do you mean progress indication messages?
[23:34] <AfC> jelmer: yes?
[23:35] <AfC> The stuff that spews out on teminal for 10ms then gets erased whenever you do anything
[23:36] <AfC> jelmer: [are those "progress indication messages"?]
[23:37] <jelmer> I'm not sure which messages you mean, I haven't seen any messages from bzr get erased when I type stuff.
[23:37] <jelmer> AfC: can you give an example of the contents of one of those messages?
[23:37] <AfC> jelmer: "...Inserting stream..."
[23:38] <jelmer> ah, those are indeed the progress indication messages
[23:38] <jelmer> adding a newline there will mean *a lot* of output though
[23:39] <jelmer> it's not a generic status message, it just tells you what bzr is working on; if something completes quickly enough it's not shown
[23:39] <AfC> I'd obviously want to nuance it that things that are just updating the 0/100 wouldn't trigger the \n, just a changed message
[23:40] <jelmer> AfC: I think you're just asking for more high-level output on what's actually been completed?
[23:40] <AfC> jelmer: I want to evaluate (subjectively) the impact of seeing more output from bzr when running things. We all know git "seems" faster, and I want to see whether that has to do with it looking like it's "doing more" per unit time / per unit message
[23:41] <AfC> jelmer: [but as an aside, having no idea what any of Bazaar's messages actually are makes it harder for all of us user types to communicate with the bzr hackers about "why it is doing ____"]
[23:41] <AfC> jelmer: [so I'd like to start seeing 'em]
[23:42] <jelmer> AfC: the related code is in bzrlib/uyi/text.py, see show_progress()
[23:42] <jelmer> s/uyi/ui/
[23:43] <AfC> Eeeek!
[23:44] <AfC> http://bazaar-vcs.org/bzr/bzr.dev/ is permanently redirected to http+urllib://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/
[23:44] <AfC> bzr: ERROR: Cannot lock LockDir(http+urllib://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
[23:44] <AfC> what the heck/
[23:44] <AfC> from
[23:44] <AfC> $ bzr pull
[23:44] <AfC> oh... it's a format 1.14 branch. Is bzr.dev 2a yet?
[23:44] <AfC> still, that's some error message
[23:45] <jelmer> yeah, I'm pretty sure bzr.dev is 2a
[23:45] <jelmer> AfC: is this a checkout perhaps?
[23:45] <AfC> jelmer: yeah, I assume so
[23:45] <AfC> jelmer: I always do "read-only" checkouts (mirrors?) of upstream.
[23:45] <AfC> Shouldn't I?
[23:46] <jelmer> AfC: you can, but you should in that case use "bzr up" to update
[23:46] <jelmer> AfC: you were trying to pull new changes into your local branch and its master branch, to which you have no write access
[23:46] <jelmer> (the error message about the master branch being readonly is more than weird, I admit)
[23:46] <AfC> jelmer: update vs pull sometimes being one thing and sometimes being another is probably THE thing I hate the most about bzr, :(
[23:47] <AfC> In a branch, regardless of what type it is, it should be pull, or update. They shouldn't be the same sometimes.
[23:47] <jelmer> AfC: hopefully it's something that will be addressed in the 3.0 UI revamp
[23:47] <AfC> I hope we can clean this up in 3.0
[23:47] <AfC> jelmer: tag you're it
[23:47] <jelmer> AfC: well, technically they are different things.. but I won't go there, I get your point.
[23:48] <AfC> jelmer: I know they're different things. That's why I'd rather they be 2 commands that you have to do
[23:48] <AfC> jelmer: the whole thing is founded in the idea that "people shouldn't have to do two steps" but look at the confusion that resulted.
[23:49] <AfC> jelmer: if pull and update are different and have side effects, then they're different.
[23:49] <AfC> {shrug}
[23:50] <AfC> Meanwhile, starting again,
[23:50] <AfC> $ bzr branch http+urllib://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/
[23:50] <AfC> can't give me an estimate of total size to be transfered? :(