[00:24] <igc> morning
[01:05] <poolie> hello igc
[01:08] <poolie> spiv, (garyvdm): so what was the outcome re that patch and 1.12?
[01:09] <igc> hi poolie
[01:12] <lifeless> igc: hi
[01:12] <lifeless> igc: is it ok with you if I rename 1.12-preview to development4, or whatever the current sequence number is up to ?
[01:12] <lifeless> igc: (its why we use a different namespace, the problem of predicting when-ready)
[01:13] <igc> lifeless: the format's ready. It's just not reviewed :-) :-)
[01:14] <igc> lifeless: seriously ...
[01:14] <igc> my concern with developmentN in this case is that ...
[01:15] <igc> it's not related to any of the other development formats in any meaningful way ...
[01:15] <lifeless> igc: why is that a concern?
[01:15] <igc> i.e. it's not built on N-1, not is it an experiement towards N+1
[01:15] <igc> potential confusion
[01:16] <igc> lifeless: I'm happy to rename it btw ...
[01:16] <igc> just not sure developmentN is the best choice but it's no big deal
[01:16] <lifeless> can you read the rationale in doc/developers/development-repo.txt
[01:16] <igc> I did
[01:16] <lifeless> its a little repo centric, but I did envisage branch and tree doing the same thing
[01:17] <igc> at the time, new development formats were coming thick and fast in brisbane-core
[01:17] <lifeless> 1.12-preview is just as confusing as devN IMO - see the question from Karl
[01:17] <lifeless> 1.12-preview as named appears more solid than dev4, when its really a separate dimension, as we both know
[01:18] <lifeless> I'd personally prefer devN because we have docs about that, and a defined way for people to find out what it does differently
[01:18] <lifeless> lower learning curve
[01:19] <igc> fair enough. I don't want to waste our time arguing about this btw ...
[01:19] <lifeless> alternatively, if you want a different approach, perhaps use a namespace that maps to tree ;P
[01:19] <lifeless> igc: me neither, was just trying to be clear
[01:19] <lifeless> igc: thank you
[01:19] <igc> "maps to tree"?
[01:19] <lifeless> well, development-wt1
[01:19] <lifeless> or something
[01:20] <igc> ok, that's better by me
[01:20] <lifeless> cool, its fine by me.
[01:20] <igc> lifeless: would development-wt5 be ok you think?
[01:21] <lifeless> igc: yeah, thats fine IMO.
[01:21] <igc> lifeless: I'll put a patch up.
[01:21] <lifeless> igc: it does lead to 'how do we do a new tree+branch+repo' as a question, but we can cross that another time, or just collapse back to developmentN
[01:21] <igc> lifeless: just reviewing your unshelve patch now btw
[01:22] <lifeless> igc: thanks
[01:22] <igc> lifeless: did you get any feedback from abentley on it so far?
[01:23] <lifeless> none that I can see
[01:27] <Phill> Hey, I used the bzr remove command on something I shouldn't have removed, how can I find the file and bring it back from the death?
[01:28] <Odd_Bloke> Good evening.
[01:30] <igc> hi Odd_bloke. Nice to see the patches flowing from you again!
[01:30] <Phill> Up, nevermind, I figured it out.
[01:30] <igc> Odd_Bloke: ^^
[01:30] <Odd_Bloke> igc: It's nice to have found some time to send them. :)
[01:31] <Odd_Bloke> Thanks for the reviews, BTW.
[01:31] <igc> np
[01:31] <jelmer> hey Odd_Bloke
[01:31] <jelmer> Managed to get home safely?
[01:31] <Odd_Bloke> jelmer: Yup.
[01:31] <jelmer> hi Ian
[01:33] <Odd_Bloke> jelmer: How was your journey?
[01:33] <jelmer> Odd_Bloke, pretty good
[01:33] <jelmer> Odd_Bloke, there was some power blackout
[01:33] <jelmer> which meant that the train was redirected *through* my home town, saving me some transfers
[01:34] <jelmer> (and causing them for most of the others)
[01:34] <Odd_Bloke> Heh, nice.
[01:34] <Odd_Bloke> Well, not so nice for them. :p
[01:35] <igc> hi Jelmer
[01:35] <garyvdm> poolie,spiv: I've hacked a quick fix for qbzr re:TooManyConcurrentRequests bug.
[01:36] <poolie> in to bzr or into qbzr?
[01:37] <garyvdm> poolie: into qbzr
[01:37] <poolie> ok
[01:37] <poolie> so we're ok to merge that if we want?
[01:37] <garyvdm> Sure
[01:37] <garyvdm> Yes
[01:43] <Odd_Bloke> The test suite seems much slower than it used to be.
[01:44] <lifeless> thanks igc
[01:51] <KhaZ> Ooh.  Just encountered that TooManyConcurrentRequests error.  Is there a good end-user work around for it?
[01:51] <KhaZ> (Win32, bzr 1.11)
[01:54] <garyvdm> KhaZ: is it in qbzr?
[01:54] <lifeless> KhaZ: using the gui?
[02:00] <garyvdm> Khaz: if you are using bzr 1.11 -  then it can't be the same bug I was talking about just now. Please could you file a bug report.
[02:19] <Odd_Bloke> garyvdm: Thanks for the pointer to the upload stuff, I'll look at that when I'm next looking at stuff.
[02:19] <Odd_Bloke> garyvdm: On a sidenote, are you aware that your Reply-To is set to qbzr@googlegroups.com?
[02:20] <garyvdm> Odd_Bloke: Pleasure
[02:20] <garyvdm> Yes
[02:20] <Odd_Bloke> Cool.
[02:20] <Odd_Bloke> I think I shall call it a night.
[02:20] <garyvdm> gmail does not allow you to change you reply-to for 1 msg :-(
[02:20] <garyvdm> Forgot to change it back
[02:22] <KhaZ> OK.  I'm using bzr from the command line on windows
[02:23] <KhaZ> If anyone wants to have a look: http://pastebin.com/m66706082
[02:23] <KhaZ> I'll put it into the tracker however.
[02:25] <lifeless> KhaZ: from the CLI it probably indicates a permissions issue or something similar
[02:26] <lifeless> KhaZ: it *may* be a bug
[02:30] <KhaZ> Hrmm.  I suppose that's a possibility.  I mean, I'm accessing a linux repo from windows, so anything's possible.
[02:30] <KhaZ> Although the authentication I'm using is ssh, and I've always accessed the share the same way
[02:31] <lifeless> is there a backtrace on the server in its .bzr.log
[02:32] <KhaZ> Ooh, you're a clever one lifeless.  lemme check.
[02:32] <KhaZ> Hrmm, doesn't appear to be.
[02:33] <KhaZ> But I imagine it wouldn't be anyways.  THe backtrace in the client is barfing on '_send_request'... I'm guessing the server hasn't even been involved yet.
[02:33] <KhaZ> What is a 'SMartSSHClientMedium' anyhow?
[02:34] <lifeless> one step up from serialisation, its a broker for requests to the server
[02:35] <garyvdm> Night all
[02:38] <fullermd> About halfway between SmartSSHClientRare and SmartSSHClientWelldone.
[02:39]  * KhaZ drums a rimshot
[02:39] <KhaZ> Ah, you know what, I bet you're right and this is a permissions issue.  I just rebuilt my MSYS on windows, and I bet it's trying to log me in with the wrong case....
[02:39] <KhaZ> Hrmmm.. Now where do I set my ssh username in bzr...
[02:41] <KhaZ> Oh holy hell.  The whole concept of --local just made sense to me.
[02:41] <KhaZ> So if I bzr branch off some other server to my local copy, I'm essentially commiting against that 'other server's copy of code, yeah?
[02:41] <fullermd> Not if you branch, no.
[02:41] <lifeless> if you checkout
[02:41] <KhaZ> ANd --local emulates as if I've got a local repository on my HD, until such time as I commit normally?
[02:41] <fullermd> --local is for shooting yourself in the foot if you checkout.
[02:41] <KhaZ> Hahah
[02:42] <lifeless> KhaZ: --local is for treating a checkout like a branch for a short period of time
[02:42] <KhaZ> Hrmm..  So checkout is more akin to svn co, I guess.
[02:42] <KhaZ> Right.
[02:42] <lifeless> KhaZ: checkout is intended to be identical to svn co/cvs co/etc
[02:42] <KhaZ> Can I see whether I have a branch or a checkout somehow?
[02:42] <lifeless> bzr info
[02:43] <KhaZ> Faaaaancy.
[02:43] <KhaZ> Hrmm, so apparently I am bound with the right username.  Bizarre.
[02:46] <lifeless> KhaZ: two things
[02:47] <lifeless> KhaZ: firstly you don't need '.' in your commit line
[02:47] <lifeless> its the default ;)
[02:47] <lifeless> secondly, the 'bash: bzr: command not found' says to me bzr can't find bzr on the server
[02:50] <KhaZ> Hrmm.  Good catch.  Definitely tr...
[02:50] <KhaZ> Oh damn
[02:50] <KhaZ> I switched the server over from using gentoo's version of bzr to the copy I have with a patch.
[02:50] <KhaZ> I bet that's got something to do with it.
[02:51] <KhaZ> THank God, too.  Traversing that smart ssh code was making me feel dumb.
[02:52] <fullermd> You should try starting with ReasonablyIntelligentSSHClientMedium and working up.
[02:53] <lifeless> fullermd: slow day? :P
[02:53] <KhaZ> Haha.
[02:54] <fullermd> Well, it's early morning, and I'm desperately trying not to have to get into the work I need to do...
[02:54] <KhaZ> fullermd: You in Australia/NZ?
[02:54] <fullermd> Oh, no.  US.
[02:54] <fullermd> I'm just surrounded by people who keep weird hours   :p
[02:55] <fullermd> (~300 million of them to be precise.  My life would be so much easier if they'd just stay in sync with me...)
[02:55] <KhaZ> fullermd: Try ReasonablyIntelligentRSync and work up. ;)
[02:55] <KhaZ> HeeHee, it is fun!.
[03:03] <KhaZ> Hrmm.  Does bzr do it's actions in some sort of different usermode than if I were to ssh in manually?  It must, I just can't figure how to emulate it.
[03:04] <lifeless> KhaZ: no, 'ssh host bzr --serve --allow-writes /' or something like that
[03:04] <lifeless> there is an environment variable to control what it thinks bzr is called - BZR_REMOTE_SSH or something like that
[03:06] <fullermd> BZR_REMOTE_PATH
[03:06] <KhaZ> Right.  Just weird - bzr exists on the command line in the path.  I'm guessing that it's in /usr/local/bin that's the problem.  Just not sure where/who I have to say "Hey!  Look in /usr/local/bin, douche!" to.
[03:06] <KhaZ> Right, but that's a per repository or per client setting, yeah?
[03:06] <KhaZ> I'm thinking it's better if I just fix my server.. This *was* working.
[03:06] <lifeless> yes :P
[03:08] <KhaZ> ... now if only I could find out where. ;)
[03:19] <lifeless> late fooding
[03:45]  * igc lunch
[03:50] <poolie> lifeless: ping?
[03:50] <poolie> lifeless: i'm thinking about whether to push for an SRU for a whole bzr release
[03:50] <poolie> or just to get it into backports
[04:21] <lifeless> poolie: well, backports is a good start
[04:21] <lifeless> but an SRU isn't done trivially
[06:31] <Demosthenes> i've done some searches with little luck. what is the status of nesting repositories?
[07:15] <vila> hi all
[08:14] <mwhudson> in a test suite, i want a revision object
[08:15] <mwhudson> oh hm
[08:57] <davidstrauss> Is it possible to clean up unused revisions stored in a shared repository?
[08:58] <Lo-lan-do> davidstrauss: Not yet, but LarstiQ and I (but mostly LarstiQ :-) started a gc plugin two days ago at FOSDEM.
[08:59] <davidstrauss> nice
[08:59] <davidstrauss> Lo-lan-do: gc plugin?
[08:59] <Lo-lan-do> I'm about to migrate to a proper workplace in a few minutes, but I'll be online again later.
[08:59] <Lo-lan-do> garbage collector
[08:59] <Youssef> hi guys!
[08:59] <davidstrauss> ah
[08:59] <Youssef> how are u?
[09:00] <davidstrauss> Happy that the Drupal Paris sprint is underway
[09:01] <lifeless> davidstrauss: excellent
[09:02] <lifeless> davidstrauss: hey, we haven't reproduced that windows users bug yet
[09:02] <davidstrauss> lifeless: Let me email him for his directory
[09:02] <lifeless> davidstrauss: but a different issue I've found which caused the 'corruption' is something I will be fixing, which at least would mean things get pushed correctly
[09:02] <lifeless> davidstrauss: I think you gave us a copy already?
[09:02] <davidstrauss> lifeless: Not *his* checkout
[09:02] <davidstrauss> lifeless: I'd be happy implementing something that would have caught this pre-commit.
[09:03] <davidstrauss> lifeless: If there's an immediate error, it will be much easier to catch in the future
[09:18] <dholbach> hi guys
[09:18] <dholbach> jelmer: where does Debian get python-subvertpy from?
[09:18] <dholbach> jelmer: just checking out the bzr* sync requests
[09:19] <dholbach> bug 325930 is the one I was stumbling over
[09:21] <lifeless> davidstrauss: indeed, but we need a good theory of what happened to do that :P
[09:21] <davidstrauss> lifeless: We know it failed bzr check after that revision got added.
[09:22] <davidstrauss> lifeless: So it's detectable, albeit inefficiently.
[09:36] <jelmer> dholbach, hi
[09:36] <jelmer> dholbach, subvertpy is in NEW
[09:36] <dholbach> jelmer: hrm :-/
[09:36] <dholbach> makes it somewhat hard to sync :-/
[09:37] <jelmer> dholbach, I can upload to REVU if that makes things easier for Ubuntu
[09:38] <dholbach> jelmer: or just put it up somewhere and link to it in the bug report - I'll review and ask the archive admins what needs to be done
[09:38] <dholbach> (the source package)
[09:38] <dholbach> luckily the bzr-svn is in universe so we don't need to write a main inclusion report for subvertpy :)
[09:39] <jelmer> dholbach: :-)
[09:39] <dholbach> jelmer: thanks for helping out there!
[09:39] <jelmer> dholbach, I'll upload a source package this afternoon, gotta run now
[09:40] <dholbach> rock and roll
[09:40] <dholbach> have a great day
[10:53] <Youssef> hi guys
[10:53] <Youssef> I have a problem
[10:54] <Youssef> im working with vista
[10:54]  * Lo-lan-do sympathizes
[10:54] <Youssef> looool
[10:54] <Youssef> yes but
[10:54] <Youssef> okay
[10:55] <Youssef> I explain
[10:55] <Youssef> im creating a folder it looks like this check
[10:57] <Youssef> I would like to create a folder with my project
[10:57] <Youssef> but i want it to work in a server
[10:57] <Youssef> im working with my computer
[10:57] <Youssef> alo?
[10:57] <Youssef> i there someone?
[10:58]  * Lo-lan-do doesn't understand the problem
[10:58] <Youssef> lol
[10:58] <Youssef> okay
[10:59] <Youssef> i repeat more clearlly
[10:59] <Youssef> mmhhh
[10:59] <Youssef> just a second
[10:59] <Youssef> localy I create a server
[10:59] <Youssef> with a shared foler
[10:59] <Youssef> check
[11:00] <Lo-lan-do> What's a server?
[11:02] <Youssef> C:\>mkdir MyOfficialProject
[11:02] <Youssef> C:\>cd MyOfficialProject
[11:02] <Youssef> C:\MyOfficialProject>bzr init
[11:02] <Youssef> Standalone tree (format: pack-0.92)
[11:02] <Youssef> Location:
[11:02] <Youssef>   branch root: .
[11:02] <Youssef> C:\MyOfficialProject>bzr add
[11:02] <Youssef> Added files
[11:02] <Youssef> C:\MyOfficialProject>bzr commit -m "Initial Commit"
[11:02] <Youssef> Committing to: C:/MyOfficialProject/
[11:02] <Youssef> Added files.
[11:02] <Youssef> Committed revision 1.
[11:02] <Youssef> C:\MyOfficialProject>bzr serve
[11:03] <Youssef> listening on port:  4155 ...
[11:03] <Lo-lan-do> Please use pastebin for pasting stuff!
[11:03] <Youssef> this is what a do for a dedicated server
[11:03] <Youssef> Oops sorry
[11:03] <Youssef> really sorry
[11:04] <Youssef> I prefer rafb
[11:04] <Youssef> http://rafb.net/p/FHobII85.html
[11:04] <Youssef> check
[11:05] <Youssef> Logically my folder is a shared folder
[11:05] <Youssef> no?
[11:05] <Lo-lan-do> I don't know.  What do you mean by shared folder?
[11:05] <Lo-lan-do> (I'm clueless with Windows, you'll have to forgive me)
[11:06] <Youssef> hmm :)
[11:06] <Youssef> I imagine
[11:06] <Youssef> okay
[11:07] <Youssef> listen i just want to create a project in a distant server from where ill be able to simply checkout it to my laptop
[11:07] <Youssef> how a can do that please?
[11:07] <Lo-lan-do> Can't you connect to your server?
[11:08] <Youssef> no no i can connect but when I chek it out he is the server log
[11:08] <Youssef> http://rafb.net/p/M991cN26.html
[11:10] <Youssef> what is it?
[11:13] <Lo-lan-do> Not sure.  Firewall?
[11:13] <Lo-lan-do> How did you try to access the server?
[11:18] <LarstiQ> Lo-lan-do: thanks, I branched bzr-gc
[11:18] <Lo-lan-do> LarstiQ: You probably saved yourself, oh, I don't know, at least five minutes of work :-)
[11:18] <Youssef> in localhost
[11:19]  * LarstiQ grins at Lo-lan-do 
[11:19]  * Youssef hope in Lo-lan-do
[11:19] <Lo-lan-do> LarstiQ: Thanks by the way, bzrlib is no longer a scary monster to me.  It's just a large unknown beast now.
[11:19] <Lo-lan-do> Youssef: Command line?
[11:19] <Youssef> ???
[11:20] <Youssef> what?
[11:20] <LarstiQ> Lo-lan-do: the motivational aspect is the important bit, I'm going on a ~24 hour trip now, so I'm hoping to hack more on it if the power is with me.
[11:20] <Lo-lan-do> What was the command like you used?
[11:20] <LarstiQ> Lo-lan-do: that's good to hear
[11:20] <Youssef> okay check
[11:21] <Youssef> WHAT?
[11:21] <Youssef> Lo-lan-do:
[11:21] <Youssef> when i do => C:\LocalCopy>bzr branch bzr://localhost/
[11:21] <Youssef> Branched 1 revision(s).
[11:21] <Youssef> and it copy the folder where i am
[11:22] <Youssef> is it correct?
[11:22] <Lo-lan-do> Looks like so.
[11:26] <Youssef> when
[11:26] <Youssef> C:\LocalCopy>bzr checkout bzr//localhost
[11:26] <Youssef> bzr: ERROR: Not a branch: "C:/LocalCopy/bzr/localhost/".
[11:27] <Lo-lan-do> Missing :
[11:29] <Youssef> Lo-lan-do! juste come back to : http://rafb.net/p/FHobII85.html
[11:29] <Youssef> is it correctly done?
[11:30] <Youssef> with my computer it seems to be correct
[11:30] <Lo-lan-do> It looks like it is, and since you managed to branch from it I don't see what the problem is.
[11:30] <Youssef> hhmm okay
[11:30] <Youssef> stay there im comming
[11:31] <Youssef> forgot the branch
[11:32] <Youssef> okay
[11:32] <Youssef> now
[11:32] <Youssef> when my server works
[11:32] <Youssef> as client what do i have to do to get a copy of the project
[11:34] <Youssef> bzr checkout bzr://localhost/MyOfficialProject ?
[11:35] <Youssef> C:\LocalCopy>bzr checkout bzr://localhost/MyOfficialProject
[11:35] <Youssef> bzr: ERROR: Not a branch: "bzr://localhost/MyOfficialProject/".
[11:35] <Lo-lan-do> You did it already: bzr branch bzr://localhost/
[11:36] <Youssef> yeah but do I have to do it first i chekcout?
[11:36] <Lo-lan-do> ?
[11:37] <Youssef> lol okay in english now
[11:37] <Youssef> do I have to do a branch before a checkout?
[11:37] <Lo-lan-do> Depends on what you want to do.  Do you want a branch or a checkout ?
[11:37] <Youssef> first a checkout
[11:38] <Lo-lan-do> Then just do a checkout.
[11:38] <Youssef> in a simple directory ? or a have to do sometings before a ckekout
[11:39] <Lo-lan-do> Just do a checkout :-)
[11:39] <Lo-lan-do> You're not using git, things are supposed to just work here.
[11:40] <Youssef> loooool the checkout successed ppfff
[11:40] <Youssef> okay stil stay with me
[11:41] <Youssef> I have done a "C:\LocalCopy>bzr checkout bzr://localhost/"
[11:47]  * Lo-lan-do → food
[14:15] <matkor> Hi ! I did bzr push bzr+ssh://<remote>/<dir>         Now how can I see WT in <dir> ?
[14:15] <beuno> matkor, no, push to remote locations doesn't produce WT
[14:15] <matkor> bzr update   gives:   bzr: ERROR: No WorkingTree exists for <dir>
[14:16] <matkor> bueno: So how can I get WT in <dir> ?
[14:16] <beuno> matkor, via a plugin
[14:16] <awilkins> ssh me@remote ; cd <dir> ; bzr up
[14:16] <beuno> you have either push-and update
[14:17] <beuno> or, bzr-upload, which *just* uploads the WT
[14:18] <matkor> awilkins: I get bzr: ERROR: No WorkingTree exists for "file:///<dir>/.bzr/checkout/"
[14:18] <jdong> he meant bzr co
[14:18] <jdong> you run bzr co the first time, bzr up subsequent times :)
[14:19] <jdong> (check out a working tree, update existing working tree)
[14:20] <matkor> Ah ! Right. Thank you very much jdong, awilkins
[14:20] <matkor> and bueno
[14:32] <Toksyuryel> I just thought of something. for a "clone" checkout (i.e. where the user is downloading the tree for the very first time and does not currently have a working copy) is it really necessary to send each file one-by-one? would it be better to compress and archive them first and just send that?
[14:33] <Lo-lan-do> I think what goes over the network is actually the repository, and the files are checked out of the new copy.
[14:34] <phinze> hey so how does bzr play with symlinks in a repository?  i'd like to have a "latest" symlink in my "releases" subdir that points to the last release branch
[14:34] <phinze> will that confuse bzr?
[14:34] <Lo-lan-do> phinze: It my experience it seems to work.
[14:34] <Lo-lan-do> But that may confuse users, since the contents of a stable URL may change.
[14:35] <phinze> Lo-lan-do: it's for internal use in a department where we have a weekly release cycle
[14:35] <Lo-lan-do> I'm jus' sayin' :-)
[14:35] <phinze> right, this is true
[14:36] <Lo-lan-do> It's basically the same as rebasing a public branch.  If your users expect it, no problem.
[14:36] <phinze> also, thanks :)
[14:36] <phinze> sounds good
[14:41] <phinze> so now if i have a local branch of "latest", and the symlink has been moved to a new release, i can "bzr pull"? or must i remove and rebranch?
[14:42] <Lo-lan-do> You can pull if the new one is a direct descendant of the previous "latest".
[14:42] <phinze> hmm... new one will be branched off a later revision of trunk
[14:42] <Lo-lan-do> If histories have diverged, you'll need to either merge or pull --overwrite.
[14:42] <phinze> not sure if that constitutes "direct descendent"
[14:43] <fullermd> pull --overwrite will probably be faster and easier than removing and rebranching...
[14:43] <phinze> probably pull --overwrite will be what i want, as it will just be used as a mirror for diffing
[14:43] <fullermd> Roughly speaking, if the "release branch" is an older version of trunk, the history isn't diverged.
[14:44] <fullermd> It diverges if a commit is made on the release branch that wasn't pulled from trunk.
[14:44] <fullermd> So it really depends on what "release branch" means.
[14:44] <phinze> ahh okay
[14:45] <phinze> yeah we're still developing our software release procedure w/ bazaar, but we're thinking in the case of an emergency we'll have a commit directly to the release branch that we merge back into trunk
[14:45] <phinze> so in that case we may have diverged
[14:45] <fullermd> If it's merged back into trunk, then trunk becomes a superset of the release branch, so pull can work.
[14:45] <phinze> ah wow
[14:45] <phinze> nice
[14:46] <fullermd> It's all revision based.  If trunk contains the head revision of the release branch, it's a proper superset, and if it's a proper superset, you can pull.
[14:46] <phinze> cool
[14:46] <phinze> man i'm still only scratching the surface of this domain of knowledge :)
[14:47] <fullermd> An alternative would be to use tags for the releases, and a sliding tag for the latest.  If it's very rare that you commit onto a release branch, that may be simpler.
[14:47] <fullermd> (or it may not, considering tag propogation issues)
[14:48] <phinze> yeah we looked into that, but we were hesitant because of a bug we encountered having to do with tags not being pulled until a revision is bumped in some other way
[14:48] <phinze> perhaps that is referring to the "tag propogation issues" you mention
[14:49] <fullermd> Mmm.  I'm pretty sure they always pull.  Maybe they don't propogate with merge unless there are revs to merge.
[14:49] <fullermd> I was thinking more of the lack of versioning causing headaches when they change.
[14:49] <phinze> ah yeah that's another issue
[14:50] <fullermd> (wihch doesn't matter for the release tags, but sure as heck does for a slider)
[14:51]  * fullermd waves at bialix.
[14:51] <phinze> right right
[14:51]  * bialix waves at my here
[14:51] <bialix> err
[14:51] <bialix> pfff
[14:51] <bialix> sorry
[14:51] <bialix> hi fullermd
[14:51] <bialix> I wish to have nested trees year ago
[14:54] <bialix> LarstiQ: new layout almost finished
[14:54] <bialix> LarstiQ: i.e. Ive started using it. I think nested trees should be killer feature. Sad they are not here
[14:56] <bialix> ubotu
[14:56] <bialix> ubottu
[15:00] <bialix> sorry for noise
[15:03] <Odd_Bloke> jelmer: Thanks for the reviews. :)  I'll look at the tweak this evening.
[15:12] <kirkland> is it possible to edit an existing commit message, for a previous revision?
[15:14] <beuno> kirkland, no
[15:14] <beuno> but you can uncommit
[15:15] <beuno> and commit again with a new message
[15:15] <kirkland> ah
[15:15] <kirkland> beuno: beuno
[15:16] <beuno> recursive me!
[15:16] <kirkland> :-)
[15:26] <awilkins> kirkland: Problem with uncommit is if other people have branches based on the revision(s) you've uncommitted
[15:33] <kirkland> awilkins: thanks, gotcha.  i think this is just a one time deal
[15:58] <vila> abentley: ping
[15:59] <abentley> vila: pong
[15:59] <vila> is read_bundle_from_url still useful or can it be deprecated ?
[15:59] <vila> abentley: the reason I ask is that it causes problems in tests
[16:00] <abentley> vila: lemme see...
[16:00] <vila> because it's an url based API, it fools the test framework when special purposes transports must be used
[16:01] <vila> the root cause is the get_transport call in read_mergeable_from_url (i.e. we have read_bundle_from_url -> read_mergeable_from_url -> read_mergeable_from_transport)
[16:04] <abentley> vila: So read_bundle_from_url is a problem but read_mergeable_from_url is not?
[16:04] <vila> it's a problem too but I found a work around for it in the tests ;-)
[16:05] <vila> because it accepts a possible_transports parameter !
[16:05] <abentley> vila: That does not sound good, but I'm okay with deprecating read_bundle_from_url.
[16:05] <vila> I can add a possible_transports parameter to read_bundle_from_url too, but I thought that if some cleanup was possible it was better to do so
[16:06] <vila> I agree, that's not the proper fix, the problem is that there are tests that are buggy today
[16:06] <vila> i.e. they declare to test a transport while in fact they use another
[16:06] <abentley> vila: You may also be able to eliminate the _do_directive parameter.
[16:07] <vila> nobody can detect that yet, I ran into it while using a special https transport
[16:07] <vila> eliminate the _do_directive parameter ?
[16:08] <abentley> vila: I believe it's only false when called by read_bundle_from_url.
[16:09] <vila> aah, you mean once read_bundle_from_url is deprecated ?
[16:09] <abentley> I did, but actually, that must wait until it's removed.
[16:09] <vila> ok
[16:09] <vila> thanks, I'll do that (deprecate) then
[16:45] <theAdib_> does bzr handles svn branches via https? i.e. bzr branch https://server/pathtorepos
[16:47] <jelmer> theAdib_, yes
[17:02] <theAdib_> jelmer, so how can I enter username and password for that connection? I get: Unable to handle http code 401: Authorization Required
[17:07] <jelmer> theAdib_: make sure you have a new bzr-svn (0.5.0) and specify the username in the URL
[17:15] <theAdib_> I am on win32 using latest bzr 1.11,
[17:16] <theAdib_> and that worked thx, jelmer ! :-)
[17:32] <KhaZ> There's no way to do partial checkouts of a tree in bzr, correct?
[17:34] <santagada> KhaZ: partial checkouts of a branch is not supported ATM
[17:36] <jelmer> KhaZ, there's a partial implementation waiting to (hopefully) go into 1.12
[17:37] <phinze> a partial implementation of partial checkouts? ;D
[17:37] <jelmer> :-P
[17:46] <KhaZ> exxxxciting.
[17:46] <KhaZ> How partial, exactly?
[17:46] <santagada> jelmer: will it need changes on the repo format or is it only a client thing?
[17:46] <santagada> or is it client/server thing but not repo format dependant?
[17:47] <jelmer> it needs a new repository format (which will not be stable as of 1.12)
[17:47] <jelmer> it's partial in that it is specific to the working tree
[17:47] <jelmer> you'll still need the full branch history
[17:57] <KhaZ> jelmer: Is 'full branch history' just everything under .bzr ni a repo?
[17:58] <jelmer> KhaZ, yeah, basically
[17:58] <KhaZ> OK, I supopse that's not so bad.  A bit bizrre to think that one directory will sync almost 900 MB, but not as bad as the 2 GB in the full repo!
[18:35] <phinze> what's a good way to get patch-level confirmation of a merge?
[18:35] <phinze> "yes this, not that, not that, yes this" etc
[18:38] <nDuff> phinze, ...patch-level, not hunk level? AIUI, it's most common to do cherry-picking (what that workflow is called) on the commandline setting up the merge, not afterwards but prior to committing.
[18:38] <phinze> nDuff: sorry i meant hunk level
[18:39] <asabil> phinze: check the bzr-interactive plugin
[18:39] <nDuff> phinze, (actually, doing it patch-level *is* supported, too: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#reverse-cherrypicking)
[18:39] <asabil> well the bzr-interactive only gives you interactive commits for now
[18:39] <nDuff> phinze, ...but hunk level, I most often cheat and rely on shelve.
[18:40] <phinze> nDuff: yeah i was wondering if it could be used in that way
[18:40] <phinze> how does that work for you?  (i.e. what commands are you running roughly in what order?)
[18:40] <phinze> asabil: that looks promising, but atm i'm interested in interactive merge
[18:41] <asabil> phinze: adding interactive merges shouldn't be difficult
[18:41] <asabil> you can try to extend it, that would be pretty neat
[18:42] <phinze> asabil: cool, perhaps i'll look into it
[18:43] <phinze> nDuff: nm i can imagine it pretty well... bzr merge, then bzr shelve, and shelve things you dont want to commit
[18:49] <jdobrien> is there any clearer guidance available about the --no-trees option for init-repo?
[18:55] <jdobrien> thanks rockstar ^^^ nice post http://theironlion.net/blog/2009/01/23/more-advanced-bazaar-concepts/
[18:56] <rockstar> jdobrien, thanks!
[18:56] <rockstar> jdobrien, did that answer your questions, or do you still need help?
[18:57] <jdobrien> i think so.
[18:59] <jdobrien> rockstar: can I push my (feature) branches to launchpad from the lightweight checkout?
[18:59] <rockstar> jdobrien, yeah.  I almost never have to go into the ~/Projects/repos folder at all.
[18:59] <jdobrien> rockstar: sweet, that's what I'm looking for
[19:01] <garyvdm> jdobrien: you can run bzr push -d :bound
[19:02] <garyvdm> Then it will use the saved push location of the bound branch.
[19:02] <jdobrien> thanks garyvdm, i'll have to look that up.
[19:03] <jdobrien> i wonder how long it will take to master bzr .. probably never will
[19:06] <jdong> garyvdm: what other :names are available?
[19:06]  * jdong didn't know bzr supported those
[19:06] <garyvdm> :push, :pull
[19:07] <nDuff> Are the bzr and bzrtools releases in the PPA out-of-sync?
[19:07] <garyvdm> There must be a list somewhere, but I don't know where.
[19:07] <garyvdm> nDuff: yes
[19:07] <jdong> garyvdm: are those documented somewhere?
[19:08] <garyvdm> jdong: probably - but I don't remember where.
[19:11] <bialix> garyvdm: well done, thanks
[19:12] <garyvdm> Hi bialix - Everything correct?
[19:12] <Peng_> jelmer: ping?
[19:12] <jelmer> Peng_, pong
[19:12] <bialix> garyvdm: well, one tiny detail: you forgot to update QBzr page at bazaar-vcs.org/QBzr
[19:13] <bialix> but this is easily fixable
[19:13] <garyvdm> bialix: Oh - Do I still need to do it?
[19:13] <bialix> I can do it
[19:13] <bialix> garyvdm: actually I have  a question to you about qlog
[19:13] <garyvdm> Ok
[19:13] <Peng_> jelmer: Oh hi. Errm.
[19:14] <garyvdm> jdong: from the source code:
[19:14] <bialix> is it possible to show not all history, but revision range instead in the qlog?
[19:14] <garyvdm> :parent, :submit, :public, :push, :this, and :bound are currently supported.
[19:15] <garyvdm> bialix: there is no ui
[19:15] <jdong> garyvdm: good sleuthing; thanks :)
[19:15] <bialix> garyvdm: do you mean command-line interface UI?
[19:15] <garyvdm> and if we add a ui to do it - it would not improve the performance
[19:16] <Peng_> jelmer: I used bzr-svn 0.4 to branch an svn branch, and committed locally a few times, but never pushed back. Now that I'm using 0.5, it wants to use svn-v4 revids, confusing everything. Advice?
[19:16] <garyvdm> bialix: command-line nor gui
[19:16] <bialix> garyvdm: let's say specific example: is it possible to show qlog for pending revisions?
[19:17] <garyvdm> bialix - not yet - but I'm hopeing to do that soon - so I can reuse the new log_list widget in qcommit
[19:17] <bialix> garyvdm: or if I want to implement cherrypicking dialog to show selected revisions for picking?
[19:18] <bialix> I'm thinking exactly about situation with revision range for some spefic use cases
[19:18] <garyvdm> bialix: if you just want to filter, that easy. What tricky is to filter, and not have to load the whole revision graph.
[19:19] <bialix> at least it's the start
[19:21] <bialix> Good evening, dear bzr hackers! Is it possible to collect code coverage info for the tests?
[19:22] <garyvdm> bialix: I've just merged my log refactoring into trunk.
[19:22] <bialix> garyvdm: cool
[19:24] <bialix> garyvdm: one more question about qlog: can we create revision picker dialog based on qlog?
[19:24] <garyvdm> Yes!
[19:24]  * bialix mulling this idea very long time
[19:25] <bialix> it was super-optimistic!
[19:25] <jelmer> Peng_, 0.5 wants to use svn-v4 revids when?
[19:25] <garyvdm> Should be very easy now.
[19:25] <bialix> great! really-really great!
[19:25] <Peng_> jelmer: Whenever. "bzr merge" or whatever.
[19:26] <garyvdm> I want to use the log widget in qcommit, qannotate, and make a revision selector for push, pull, tag, merge etc...
[19:26] <Peng_> jelmer: Since I never committed back to the svn repo with 0.4, it doesn't know any better.
[19:26] <bialix> jam who knows everything: can you suggest something about coverage? mensieur vila? anybody?
[19:26] <bialix> garyvdm: you simply read my mind
[19:27] <jelmer> Peng_, "bzr svn-upgrade" should fix that
[19:27] <bialix> jelmer: hi, can you suggest something about coverage statistics?
[19:28] <vila> bialix: I think selftest has a --coverage option but AFAIK it's broken for plugins
[19:28] <jelmer> Peng_, merge isn't aware of foreign branches (yet)
[19:28] <bialix> vila: I've thoughts so, but I've re-read selftest -h 5 times and I don;t see this option
[19:29] <bialix> broken for plugins: :-[
[19:30] <bialix> it's not my day then
[19:30] <vila> bialix: That's because it's not in the online help, that's for devs, they don't read help :-)
[19:30] <bialix> ah
[19:30] <bialix> yes
[19:30] <vila> seriously, that's a bug, it should be documented
[19:30] <bialix> oh no
[19:30] <vila>     --coverage
[19:30] <vila>         Generate line coverage report in the specified directory.
[19:30] <bialix> it's not bug
[19:31] <vila> that's a global option
[19:31] <bialix> yep, PEBKAC
[19:31] <bialix> I need addtional module I guess
[19:31] <bialix> coverage.py from Ned Batchelder, is it?
[19:32] <beuno> poolie, hi. Are there still known problems with the new progress bars, or should I report the bug that status text concatenates instead of replacing eachother?
[19:32] <bialix> vila: why you said it's broken for plugin?
[19:32] <vila> bialix: I don't think it's a very serious bug, I don't remember the details but I think it has to do with the fact that the plugins aren't in PYTHON_PATH or something
[19:32] <vila> bialix: did you try it ?
[19:32] <bialix> oops
[19:33] <vila> My memory may be wrong, it may have been fixed...
[19:33] <bialix> I'd like to
[19:33] <Peng_> jelmer: "svn-upgrade" sounds a little scary. And wouldn't I need to install the rebase plugin?
[19:33] <jelmer> Peng_, yeah, that depends on the rebase plugin
[19:33] <vila> bialix: bzr --coverage cover selftest -s bp.qbzr
[19:33] <bialix> -s bp.qbzr?
[19:34] <vila> bialix: don't tell me you don't know -s bp.qbzr !!!
[19:34] <vila> Just try: bzr selftest -s bp.qbzr
[19:34] <bialix> me me me
[19:34] <bialix> I don't remember
[19:34] <bialix> I've not followed your bzr toys many months
[19:35] <vila> bp.qbzr expands to bzrlib.plugins.qbzr it will speed up running your plugin tests by orders of magnitude
[19:35] <vila> I'm sorry I didn't publicize that much :-/
[19:35] <Kobaz> mmm
[19:35] <bialix> right
[19:35] <bialix> I recall it now
[19:35] <bialix> it was your patch
[19:35] <bialix> in first half of 2008, yes?
[19:36]  * bialix using full form -s bzrlib.plugins.scmproj
[19:36] <vila> Could be, can't remember that sort of date generally :-)
[19:36] <vila> bialix: haaaa, ok, so the shortcuts are far more recent yes.
[19:36] <bialix> found in the HACKING.txt
[19:36] <bialix> Test coverage
[19:36] <bialix> [19:36] <vila> As are the ability to specify mutiple ones
[19:36] <bialix> All code should be exercised by the test suite.  See `Guide to Testing
[19:36] <bialix> Bazaar <testing.html>`_ for detailed information about writing tests.
[19:36] <bialix> not so many info
[19:37] <vila> bialix: that's right --coverage is underused :-/
[19:37] <bialix> vila: -s bp.xxx -- it's worked! nice!
[19:38] <bialix> I have obscure feeling it was the patch from spiv
[19:38] <vila> --coverage is from spiv yes
[19:38] <bialix> oh no, it soo loong to wait for oz people to wake up
[19:39] <bialix> well, thanks, you gave ne a clue
[19:39] <bialix> will test how it selftest :-)
[19:39] <vila> bialix: are you in the Kiev TZ ?
[19:39] <bialix> aha
[19:40] <bialix> UTC+2
[19:41] <vila> bialix: I see, yes, waiting for NZ will be a bit hard for you :-/
[19:41] <bialix> vila: bzr --coverage FILENAME -- that's right?
[19:41] <bialix> vila: are you not in Europe?
[19:41] <vila> bialix: no --coverage DIRECTORY
[19:42] <vila> bialix: I am in France
[19:42] <bialix> what DIRECTORY?
[19:42] <vila> bialix: one that will contain files whose names are the python modules
[19:43] <bialix> vila: should I think waiting is not so hard to you? ;-)
[19:43] <vila> try it on a sample and look (you may have to create it first, I don't remember) looking at the results things should be obvious
[19:43] <bialix> sample?
[19:43] <vila> bialix: one hour less :)
[19:43]  * bialix downloading coverage.py
[19:44] <vila> huh ?
[19:44] <bialix> you think I should not?
[19:44] <vila> I don't remember needing an additional package... I may be wrong, checking
[19:44] <bialix> vila: I'd like to not start using python-based bzr if I can
[19:45] <bialix> bzr.exe is much pleasure
[19:45] <vila> haaa. sry
[19:46] <bialix> I knew only one actively maintained coverage lib: http://nedbatchelder.com/code/modules/coverage.html
[19:46] <bialix> I suppose spiv used it
[19:47] <vila> can you just try ./bzr selftest --coverage cover -s bt.test_read_bundle
[19:47]  * bialix trying
[19:48] <vila> A quick look seems to imply using the standard trace python module
[19:48] <vila> Ok, I just run it, no need to create the cover directory, it's created automatically
[19:49] <bialix> PermissionDenied: blah-blah-blah: I've almost forgot this stuff
[19:49] <vila> rats, tests failing ?
[19:50] <bialix> 51 tests, tests passed
[19:50] <bialix> 16 leaking tests :-P
[19:50] <vila> do you have a cover directory ?
[19:50] <bialix> have the "cover" dir full of files
[19:51]  * bialix m-m-m
[19:51]  * bialix looks
[19:51] <vila> bialix: get it ? '>>>' not executed, 'n' number of executions
[19:52] <bialix> >>> not executed? you kidding
[19:53] <bialix> or the result id weird
[19:53] <bialix> how it can't execute def blah(foo):
[19:54] <bialix> vila: you're right
[19:54] <bialix> vila: about plugins
[19:54] <bialix> it don;t see my plugin
[19:54] <bialix> only launchpad
[19:55] <vila> A workaround can be to install your plugin in a directory XXX/bzrlib.plugins with XXX in PYTHON_PATH
[19:55] <bialix> so... if I'm put it inside bp, perhaps it will collect the info
[19:55] <bialix> ja!
[19:56] <vila> be aware to *not* leave it in .bazaar/plugins though...
[19:56] <vila> Bah, that's gross, we should really fix that
[19:56] <bialix> this makes my job harder
[19:56] <bialix> but actually I keep my plugins in the BZR_PLUGIN_PATH dir
[19:57] <vila> I know, that's the bug :)
[19:57]  * bialix will try suggested hack
[19:58] <bialix> merci beaucoup
[19:58] <vila> :-)
[19:59]  * bialix mutters: "I just need to create special lightweight checkout and blow"
[20:00] <vila> I'm off, report your results, I'll read it tomorrow !
[20:00] <bialix> ok!
[20:02] <imnotparanoid> hello all! I'm a new bzr user, and need some help with my "workflow" (just a quick question). can anyone spare a few minutes?
[20:04] <Peng_> jelmer: svn-upgrade doesn't edit the subversion repo or anything, right?
[20:04] <jelmer> Peng_, no
[20:04] <bialix> shoot your quick question
[20:04] <Peng_> jelmer: Alright.
[20:05] <imnotparanoid> i have a shared repo, a checkout using bzr-svn. i branch and work on them, etc. how can i create a branch on a flash drive, for example, so I can work at home?
[20:06] <imnotparanoid> (i have copied a normal branch.. but, the revisions were in the repo.. so i could not use it at home)
[20:06] <bialix> what's your OS?
[20:06] <imnotparanoid> XP @ work (where i have the repo), linux @ home. bzr 1.11 on both
[20:07] <bialix> ok
[20:07] <ericvw> Where should I post about getting an appropriate version of bzrtools in the PPA?
[20:07] <Peng_> Ergh, wait a minute. I branched off of the bzr branch too. How do I svn-upgrade the child?
[20:07] <Peng_> An idmap-file?
[20:07] <bialix> 1. create treeless repo at flash: bzr init-repo --no-trees E: (or other drive letter of your USB)
[20:07] <jelmer> Peng_, no, the upgraded ids are consistent
[20:08] <bialix> err, actually you need sensible patg
[20:08] <jelmer> Peng_, Just run svn-upgrade there as well
[20:08] <bialix> path
[20:08] <Peng_> jelmer: Oh, nifty.
[20:08] <imnotparanoid> ok.. next step
[20:08] <bialix> then do bzr push from your branch to the repo on flash
[20:08] <imnotparanoid> do i need to use the --create-prefix ?
[20:08] <bialix> you'll get the new branch inside repo on flash with full history
[20:09] <bialix> more specific example, let's say your flash drive letter E: and you create repo/ dir
[20:09] <bialix> bzr init-repo --no-trees E:/repo
[20:09] <bialix> cd your-local-branch
[20:09] <Peng_> Argh, how the heck do I tell svn-upgrade where the original svn branch is?
[20:10] <bialix> bzr push E:/repo/trunk
[20:10] <jelmer> Peng_, it's the first argument
[20:10] <bialix> this will create new branch called trunk
[20:10] <Peng_> jelmer: You mean the one that causes it to say "No repository present"?
[20:10] <jelmer> Peng_, ah, you have to give it a repository URL
[20:11] <jelmer> Peng_,  not a branch URL
[20:11] <imnotparanoid> thank you! I think I can handle it from here!
[20:11] <bialix> because you're using bzr-svn you need to specify format --rich-root-pack (or more recent) for init-repo
[20:11] <Peng_> jelmer: Oh.
[20:11] <imnotparanoid> (it hasn't crossed my mind to create another repo on the flash drive)
[20:11] <Peng_> jelmer: Indeedy, that worked.
[20:11] <Peng_> jelmer: Thank you for the help. :)
[20:11] <jelmer> np
[20:11] <imnotparanoid> (yes, i know about the --rich root-pack from the initial repo)
[20:11] <bialix> you may want to look at repo-push plugin
[20:12] <bialix> and/or multi-pull command (from bzrtools)
[20:13] <imnotparanoid> i'm still reading the documentation (i'm not sure - yet - about the differences between push/commit/branch or pull/checkout).
[20:14] <ericvw> why isn't the new 1.11 version of bzrtools in the PPA?
[20:14] <imnotparanoid> thank you for your time. i'm going to give it a try tonight! have a nice evening!
[20:15] <bialix> good luck
[20:19] <Peng_> jelmer: Thank you for the help. "bzr svn-upgrade" seems to have gone fine. :)
[20:21] <jelmer> Peng_, np
[20:21] <jelmer> Peng_, ideally "bzr merge" will do the right thing in the future
[20:21] <jelmer> once revision-id aliases work :-)
[20:23] <poolie> hello all
[20:24] <bialix> jelmer: rev-id aliases?
[20:24] <jelmer> 'morning poolie
[20:24] <bialix> hello poolie
[20:25] <jelmer> bialix, yeah, though hooks in the graph code might be sufficient for the moment
[20:26] <bialix> poolie: I hope this patch will go into 1.12: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C497A0CD9.7030005%40arbash-meinel.com%3E
[20:27] <bialix> it should fix many problems
[20:27] <poolie> it looks good to me too
[20:27] <poolie> you keep asking me about patches i've approved :)
[20:27] <poolie> although admittedly yesterday to say it caused breakage
[20:27] <bialix> no, yesterday it was garyvdm
[20:27] <poolie> is jam still around? he should be
[20:28] <jam> poolie: I'm around
[20:28] <jam> bialix, poolie: It works for "shelve" but causes some tests for things like "diff" to break
[20:28] <bialix> rats
[20:28] <jam> I can give specifics
[20:28] <jam> but basically, our lock ordering is a bit haphazard
[20:29] <poolie> diff probably has to work :)
[20:29] <poolie> i was going to start the release in about 5 hours from now
[20:29] <jam> poolie: yeah, I would guess it is something like "bzr diff -r branch:" not working correctly.
[20:30] <bialix> so, I'd better won't try to ping you both then
[20:30] <jam> poolie: you're up early, btw
[20:30] <poolie> i am
[20:30] <jam> bialix: I'll see if I can't get it working today
[20:30] <poolie> i wanted to review ian's patches
[20:30] <poolie> i don't know if they'll land for this release but my review of them is pretty overdue
[20:30] <bialix> jam: I was in big hope about locks problem'
[20:31] <bialix> but I can live without shelve2
[20:31] <jam> I still have some hope for it
[20:32] <bialix> but shelve1 required patch.exe to be present
[20:33] <bialix> anyway, I'd better stay on the side
[20:34]  * bialix hides
[20:40] <jam> btw, poolie, you forgot to package bzrtools in the ppa during the 1.11 release, which seems to cause troubles for a lot of people, we should both get it packaged, and keep an eye out for that with the 1.12 release
[20:41] <poolie> yes, i saw :/
[20:41] <poolie> also, i think it would be easier to just merge everything across
[20:41] <poolie> i wonder if people are actually using bzrtools features, or if (as one person said) they were just told it's good so they keep it installed
[20:55] <jelmer>     s = self.filesock.readline(size)
[20:55] <jelmer> TypeError: readline() takes exactly 1 argument (2 given)
[20:55] <jelmer> anybody else seeing this?
[20:55] <lifeless> jam: pooliee: I believe that is what johnf wants to help by doing
[20:55] <lifeless> jelmer: yes, it was on the list, post b john on sunday
[20:56] <jelmer> lifeless, ah, thanks
[20:56] <jam> jelmer: vila and I have posted a fix. It has to do with https and python<2.6
[21:09] <bialix> jelmer: you've mentioned launchpadbugs recently. is it the separate library?
[21:10] <jelmer> jam, ah
[21:10] <jelmer> bialix, yeah - see lp:python-launchpad-bugs
[21:11] <bialix> jelmer: is it possible to use it to mark all bugs related to milestone to mark as "Fix Released"?
[21:11] <jelmer> bialix, not out of the box
[21:11] <jelmer> but you could write a script using it that would do such a thing
[21:12] <bialix> it's very boring task, so I'm ready to write the script
[21:13] <mwhudson> beuno: hello
[21:14] <beuno> mwhudson, howdy
[21:14] <mwhudson> beuno: do you know what History.get_merge_point_list is trying to do in loggerhead?
[21:15] <mwhudson> and simplify_merge_point_list
[21:16] <beuno> mwhudson, the latter, no idea. The former, IIRC, is used to find out what revisions to look at to get the files changed in a mainline revision
[21:16] <beuno> but I get dizzy everytime I try and go in there
[21:17] <mwhudson> ok
[21:17] <mwhudson> i guess it's time to step back and say
[21:18] <mwhudson> "what information is interesting to display"
[21:18] <beuno> right
[21:18] <beuno> well
[21:18] <beuno> I think the information we're displaying is fine
[21:18] <beuno> we *could* drop the merged in revno
[21:19] <lifeless> I'd like a datestamp
[21:19] <beuno> so we don't pay the cost of the dotted revno
[21:19] <lifeless> more than a revno
[21:19] <mwhudson> i have to say
[21:19] <mwhudson> i have _no idea_ what's going to appear in the "merged in" section
[21:19] <lifeless> in a 'query again' interface, a revno is essential
[21:19] <lifeless> in a 'click through' interface, its noise unless requested
[21:20] <beuno> mwhudson, good enough reason to drop it  ;)
[21:21] <beuno> if we do manage to load stuff more lazily, then the ajax bits would be a huge performance improvement
[21:22] <beuno> igc's new API makes it pretty easy, and if we can tweak the plugin to save the cache somewhere else, everything is going to feel *very* fast
[21:22] <beuno> but, AFAICT, we have to re-write quite a few bits in LH before being able to use it
[21:22] <mwhudson> beuno: well, i harbour a perhaps naive belief that there is something useful to display here
[21:22] <mwhudson> so about revision numbering
[21:23] <mwhudson> the thing is that, in today's reality at least, numbering _one_ off-mainline revision does enough work to number them all
[21:24] <mwhudson> so taking one revision number off the page doesn't really help
[21:25] <beuno> mwhudson, if we don't fetch non-mainline revs in the changelog view, we can use jam's lazy revno API
[21:27] <mwhudson> i think that would hurt usefulness too much
[21:27] <phinze> eek! "[Errno 11] Resource temporarily unavailable"
[21:27] <mwhudson> phinze: not as scary as it sounds, are you doing a diff during a commit or something?
[21:27] <phinze> revert
[21:28] <phinze> bzr break-lock, bzr: ERROR: The lock for '/home/phinze/proj/uiris3/trunk' is in use and cannot be broken
[21:28] <phinze> but bzr info doesn't list any locks
[21:29] <beuno> mwhudson, really? The default changelog view doesn't really have to display dotted revnos. We could check to see if it's mainline revs being navigated or not
[21:31] <phinze> a ha
[21:31] <phinze> found a zombie process
[21:31] <phinze> that was running a diff | vim -
[21:31] <phinze> disaster averted :)
[21:31] <mwhudson> beuno: the unexpanded view doesn't, i guess
[21:32] <mwhudson> beuno: can i ask you to step back some more?
[21:32]  * beuno steps back more
[21:32] <mwhudson> beuno: i'm trying to think about what information we want to display, and it feels like you're trying to optimize revno display
[21:33] <beuno> alrighty
[21:34] <mwhudson> beuno: so i actually think the unexpanded changelog view is more or less right already
[21:34] <beuno> agreed
[21:35] <mwhudson> in the drop down thingy
[21:35] <mwhudson> i think we could show a bit more about the merged revisions
[21:36] <mwhudson> beuno: do you remember this screenshot? http://people.ubuntu.com/~mwh/hacked_up_changelog_view_3.png
[21:36] <mwhudson> obviously that's not right, but...
[21:37] <beuno> mwhudson, yeap, showing more information would be good
[21:37] <beuno> basically, bzr log -v, I guess
[21:37] <mwhudson> yes
[21:37] <beuno> I'd add the date next to the merged revs
[21:37] <beuno> as lifeless pointed out
[21:38] <mwhudson> yeah
[21:39] <mwhudson> i do think branch nick is useful too
[21:40] <beuno> sure, maybe even group commits by branch nick
[21:41] <beuno> would make weird sorting sometimes though
[21:41] <mwhudson> mm
[21:41] <mwhudson> i guess you need to be careful about displaying too much information too
[21:41] <mwhudson> argh argh where to start
[21:42] <beuno> mwhudson, I can think of two (very different) places:  1) start refactoring things so we can be clearer about what is being accessed, or, 2) finally implement your screenshot
[21:43] <beuno> something basic intially, just the revno, author, shortened commit message and date
[21:43] <mwhudson> what i was trying to do last night was removing history.py somewhat
[21:44] <mwhudson> i hate the way you have template -> controller -> history.py -> bzrlib
[21:44] <mwhudson> it makes the intent so hard to unpick
[21:44] <beuno> that sounds like my favorite thing  :)
[21:44] <beuno> of course, it's probably the hardest
[21:45] <mwhudson> but now i've bumped into this line of code
[21:45] <mwhudson>             merge_revids = self.simplify_merge_point_list(
[21:45] <mwhudson>                                self.get_merge_point_list(change.revid))
[21:45] <mwhudson> which is where we started :)
[21:46] <beuno> right
[21:46] <beuno> maybe that flattens it into a list instead of a graph?
[21:46] <beuno> I remember debugging it at some point
[21:48] <mwhudson> so one interpretation of a 'merge point' is 'oldest mainline revision that has it as an ancestor'
[21:49] <mwhudson> which is actually something that's a little annoying to determine with the command line client
[21:51] <poolie> hello beuno
[21:51] <beuno> hiya poolie
[21:53] <igc> morning
[21:53]  * beuno goes home, bb in ~20'
[21:53] <igc> morning beuno, mwhudson
[21:53] <beuno> mhey ig	
[21:53] <beuno> er
[21:53] <beuno> "hey igc"
[21:53] <beuno> "I hate my internet connection today"
[21:54] <mwhudson> hi igc
[22:25] <veritos> Is it possible to pull just one directory from a repository, à la Subversion?
[22:26] <bob2> no
[22:26] <veritos> Thank you.
[22:26] <bob2> well, you could bzr split, but that doesn't reduce the amount of downloaded date
[22:34] <jml> you know, that call was shorter than I expected :)
[22:35] <mwhudson> yesd
[22:35] <mwhudson> we only veered off once or twice, and not for very long
[22:35] <jam> interestingly, it is easier not to veer off when you know there are 10 other people around
[22:36] <jam> though it was still fairly long given that you have that many people to deal with
[22:36] <jam> (it wasn't *longer* than expected, just expectedly long)
[22:42] <mwhudson> beuno: i guess you're on the phone now?
[22:42] <phinze> so i've got 6 distinct commits i want to pull out of trunk before we deploy, and i'm at a loss for how to proceed
[22:42] <beuno> mwhudson, in theory, but not in practice
[22:42] <phinze> reverse merge each one and commit?
[22:42] <beuno> thumper left me for abentley
[22:43] <mwhudson> beuno: heh
[22:43] <abentley> beuno: It's alright, you can have him now.
[22:43] <mwhudson> beuno: how long are you going to be around for tonight?>
[22:43] <mwhudson> not necessarily for in depth discussion, just for sounding-board type stuff
[22:44] <beuno> mwhudson, I have quite a few more things to do, so probably within the range of "hours", on and off while I go for a run and eat
[22:44] <mwhudson> cool
[22:45] <Peng_> phinze: Probably, yeah.
[22:52] <jml> igc: the patch at http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Cd06a5cd30901260349v321f27a8uc1ab6a75bacb0f06%40mail.gmail.com%3E has all the tweaks in it.
[23:07] <phinze> gah, some of the commits i want out of trunk are sub-commits of other commits
[23:07] <phinze> sigh, i think i'm just going to comment out the crucial changes we don't want deployed :(
[23:08] <Odd_Bloke> There doesn't seem to be a great deal of shelve/unshelve blackbox testing.
[23:12] <Odd_Bloke> Is there ongoing shelve/unshelve work somewhere?
[23:17] <spiv> Odd_Bloke: not that I know of
[23:18] <spiv> Odd_Bloke: well, ISTR lifeless sent a small bug fix for it to the list recently.
[23:19] <beuno> poolie, hi. Are there still known problems with the new progress bars, or should I report the bug that status text concatenates instead of replacing eachother?
[23:19] <spiv> beuno: report
[23:19] <beuno> will do, thanks spiv
[23:20] <Odd_Bloke> spiv: OK, cool.  It seems there are a few things that could be made nicer, so I wanted to check I wasn't duplicating effort.
[23:20] <Odd_Bloke> Do all new errors need a test in bzrlib.tests.test_errors?
[23:21] <spiv> Odd_Bloke: yes, please.
[23:21] <lifeless> spiv: its merged
[23:21] <spiv> Odd_Bloke: it's amazing how easy it is to create an Exception with a broken __str__ :)
[23:25] <Odd_Bloke> Heh, like the one I was about to commit. >.<
[23:26] <lifeless> jam: if you return tonight, I filed a bug on annotate on thursday I think
[23:26] <lifeless> vila: ^ or you
[23:28] <Odd_Bloke> Two quick questions: 1: does 'shelf' seem like a reasonable bug tag to people (1.5: do we have a process for choosing bug tags?), and 2: what do people think of named shelves?
[23:29] <lifeless> Odd_Bloke: yes.no nice
[23:30] <spiv> Odd_Bloke: what lifeless said
[23:32] <igc> jml: so merging that diff, the tip is "Jonathan Lange 2009-01-25 Blackbox tests, forgot to add these earlier."
[23:32] <jml> igc: yep
[23:32] <igc> jml: that include everything?
[23:32] <jml> igc: it does.
[23:32] <jml> igc: I just checked :)
[23:33] <igc> jml: cool. Sending it off now ...
[23:33] <jml> igc: thanks.
[23:36] <lifeless> spiv: sync(
[23:38] <eydaimon> I've got a checkout on a host blah@foo.com. I want to clone it to my laptop. bzr clone bzr+ssh://blah@foo.com/my_checkout  doesn't work. what am I doing wrong?
[23:39] <eydaimon> the error is "ERROR: Not a branch"
[23:39] <Peng_> eydaimon: The path is relative to the root, not your homedir.
[23:39] <eydaimon> ok, thank you
[23:39] <Peng_> eydaimon: So, unless you actually have a directory called "/my_checkout", alongside "/usr" and "/dev"...
[23:47] <spiv> lifeless: the current code is at lp:~spiv/bzr/fetch-streaming
[23:49] <Odd_Bloke> What does 'f' in the shelve prompt mean?
[23:49] <Odd_Bloke> Looking at the code it means 'yes to all'.  So 'force'?
[23:51] <lifeless> Odd_Bloke: sounds plausible
[23:51] <lifeless> spiv: ok...
[23:52] <lifeless> spiv: I'm fooding; may I ring?
[23:52] <spiv> lifeless: sure.