[00:05] <doctormo> If I do a bzr pull, will it kill all changes done in this branch and revert it?
[00:06] <doctormo> So if there are uncommited changes, or commited changes, they'll all be reverted.
[00:08] <spiv> pull will never discard uncommitted changes.
[00:09] <doctormo> spiv: But it will do away with commited changes?
[00:10] <spiv> If you pull --overwrite to an older revision, then the later revisions will no longer be in that branch's ancestry, yes.
[00:10] <lifeless> if they aren't in the new history, yes
[00:10] <spiv> (The revisions will still exist in the repository, though)
[00:11] <doctormo> spiv: I'm just trying to work out what I'm doing in my pull code, perhaps what I mean to do is not pull but merge.
[00:11] <doctormo> What would you do if you had a parent directory that had moved forwards and you wanted to resync your working branch with it.
[00:12] <maxb> If you did pull in that case, it would tell you 'branches have diverged'
[00:12] <spiv> I'm not sure about "parent directory that had moved forwards", but generally speaking if I have a branch that I've made changes in, and I want to incorporate changes from elsewhere to the same branch, I would use 'bzr merge'.
[00:13] <doctormo> s/parent directory/parent branch/
[00:13] <maxb> It's hard to tell what you mean by 'resync'
[00:13] <doctormo> Translating bazaar speak into something your holiday developer will understanding is making my terms diverge maxb.
[00:14] <spiv> maxb: ('branches have diverged' is right if we assume the working branch has had commits made, rather than just uncommitted changes)
[00:14] <maxb> a good point
[00:15] <doctormo> So what i really mean is `bzr merge` when I have local commits and `bzr pull` when I don't have local commits (but local changes ok)
[00:15] <spiv> doctormo: in relatively simple terms, if two people both have a copy of a branch, and they have made different commits to their copies, you probably want 'bzr merge' to combine those different changes.
[00:16] <spiv> doctormo: there's "bzr merge --pull", btw, which automates "'bzr pull' if no divergence, otherwise 'bzr merge'"
[00:16] <doctormo> spiv: I think I'll try and hook into builtins for that then, I had a bad time intergrating builtins into my threaded code though.
[00:18] <spiv> doctormo: you can always take a look at the code to see how its implemented.
[00:18] <spiv> doctormo: the code in builtins.py is mostly fairly readable
[00:19] <doctormo> spiv: It is, but I'm feeling bad about copying bits out of it, like I'm removing all the checks.
[00:19] <doctormo> http://bazaar.launchpad.net/~groundcontrollers/groundcontrol/trunk/annotate/head%3A/GroundControl/bazaar.py
[00:20] <doctormo> If interested, look at the do_action methods, I think they probably should be going through builtins.
[00:22] <spiv> doctormo: perhaps you should be reusing some code from the bzr-gtk plugin?
[00:22] <spiv> (or even the qbzr plugin?)
[00:23] <spiv> They've both already wrapped lots of builtin actions into a GUI-friendly form.
[00:23] <doctormo> spiv: I already am, as much as I could. But the problem is that I have really bad constraints because of nautilus.
[00:23] <spiv> Ah ok.
[00:24] <doctormo> It took me 3 weeks to work out how to get around those contrains too, I've lost an inch of hairline ;-)
[01:53]  * spiv lunches
[03:59] <igc> hi all
[04:04] <spiv> hi igc
[04:04] <igc> hi spiv!
[07:37]  * spiv finishes up for the day
[07:52] <vila> poolie: you broke my toy ! https://bugs.edge.launchpad.net/bzr/+bug/516934
[07:57] <fullermd> Pfft.  Your toy is just too slow   :p
[08:31]  * igc dinner
[08:43] <poolie> hi vila
[08:43] <poolie> hi igc?
[08:47] <smartgpx> Greetings. Are there any Win32 supporters in - I've just encountered an odd crash that is making me feel panicky
[08:48] <smartgpx> 'Out of the blue', > bzr explore has stated throwing a MS Visual C++ runtime error.
[08:49] <smartgpx> Console reports "QVariant::load(QDataStream &s): type list unknown to QVariant." Nothing in .bzr.log
[08:51] <fullermd> I presume that's Qt-related.
[08:52] <smartgpx> Yes, so do I. But this is a setup.exe binary installer machine, so as far as I know the only Qt is in the bzr bundle
[08:52] <fullermd> Which version?
[08:53] <fullermd> (I have no idea what solutions might be BTW, so don't expect answers from me  :)
[08:53] <smartgpx> freshly re-installed bzr2.1.0rc1-1.exe AFTER first hitting the problem
[09:00] <smartgpx> other tools from the qbzr suite run OK. qlog, qplugins both look normal.
[09:01] <smartgpx> Since re-installing from the binary installer doesn't fix it I'm fearing something is trashed in my OS. But what and how/why? AV scan running now!
[09:17]  * bialix calls for Gary
[09:17]  * fullermd isn't Gary  8-}
[09:22]  * bialix waves at fullermd
[09:25] <vila> smartgpx: Don't Panic
[09:26] <vila> smartgpx: I don't know the details but igc mentioned some Qt compatibility problems citing QVariant, so at least the problem is not unknown
[09:26] <vila> smartgpx: please file a bug against bzr-explorer though better a dupe than no report
[09:27] <vila> bialix, fullermd : hey guys !
[09:27] <fullermd> Oh, no, go ahead and panic.  It's good aerobic exercise.
[09:27] <bialix> heya vila!
[09:27]  * fullermd waves at vila.
[09:27]  * vila checks its hitchhiker's guide about aerobic....
[09:28] <bialix> smartgpx: what's up?
[09:28] <vila> . o 0 (aerobic raises EBADFORCHOLESTEROL)
[09:29]  * bialix thinks we have to upgrade windows installer to pyqt 4.7 so igc won't need to break backward compatibility at such high rate
[09:31] <smartgpx> NO - I've been told to get my HDL levels down! bialix - summary on Bazaar ML
[09:31] <bialix> HDL?
[09:38] <smartgpx> High Density Lipids I think - 'Bad Cholesterol'.
[09:38] <smartgpx> Bugged as Bug#516968
[09:41] <fullermd> Lipoprotein to be precise.
[09:41] <fullermd> (and actually HDL is the soi-disant 'good' variant)
[09:42] <fullermd> So whoever wants you to get those levels _down_ is...   well...    are they in your will?   ;>
[09:42] <bialix> ubottu: please tell me about bug #516968
[09:43] <bialix> thank you!
[09:44] <bialix> smartgpx: can you try to remove explorer.conf file?
[09:44] <bialix> or something similar
[09:44] <vila> fullermd: That should be obvious but how do I make a shell script change my current working directory ?
[09:45] <fullermd> vila: Well, if I understand you, you don't, since a script (by definition) runs in its own process, and $CWD is an attribute of each process.
[09:45] <smartgpx> CONFIRM that removing explorer.conf gets Explorer running again.
[09:45] <bialix> close explorer, open again and you'll get a crash?
[09:46] <fullermd> vila: So to change the $CWD of your current shell, it would have to run in that process, not external, with all that implies.
[09:46] <vila> fullermd: so I have to . shell-script ?
[09:46]  * fullermd nods.
[09:46] <vila> rats, . `which shell` args.... how ugly :-/
[09:47] <vila> funny I never encounter the problem before...
[09:47] <smartgpx> Thanks to Simon Kersey for suggesting this.
[09:47] <fullermd> Well, maybe you could reach into /proc and manually fudge in the other process's memory.  Is that less ugly?   ;)
[09:47] <vila> fullermd: Brilliant !
[09:47] <vila> :-P
[09:48] <fullermd> Well, naturally.  I said it, didn't I?
[09:48] <bialix> smartgpx: perhaps this is because explorer in big flux
[09:48] <smartgpx> bialix - no, it re-runs OK. I didn't think to mention that I had been exploring the new preferences in r405!
[09:48] <bialix> we need to test how smooth it will upgrade from 0.11.x to 1.0
[09:49] <bialix> oh, sorry, just saw your mails in bzr ML
[09:51] <bialix> smartgpx: anyway, thanks for testing bleeding edge changes and reporting!
[09:56] <smartgpx> maybe it isn't a recent problem? Anyway, rebugged as #516976
[09:59] <bialix> bug #516976
[09:59] <vila> ubottu: pay attention please, when someone says #516976, just interpret it as bug #516976, thanks
[10:00] <vila> bialix: faster than me !
[10:00] <bialix> :-)
[10:00] <bialix> smartgpx: I will try to look on this today
[10:01] <smartgpx> fullermd: [OT] thanks for making me re-think my knowledge of cholesterol! More reading required.
[10:02] <fullermd> Amazing the things version control can lead you to thinking of   8-}
[10:08] <igc> smartgpx: see my email on the Qt issue
[10:22] <vila> fullermd: alias is my friend :D alias bzr-review='. `which bzr-review.sh`'
[10:26] <bialix> hi igc :-)
[10:32] <bialix> igc: we have to update explorer's setup.py otherwise your new fancy wear things won't go to installer/package. can we elaborate on this?
[10:45] <igc> bialix: understood. On my list for tonight.
[10:45] <bialix> ok
[10:45]  * bialix working on preparing qbzr 0.18.1
[10:46] <bialix> anybody seen garyvdm there these days?
[10:46] <igc> bialix: I'm going to fix bug 516976 asap btw
[10:47] <bialix> igc: that's will be nice. if you need quick testing ping me
[10:47] <igc> shall do
[10:51] <poolie> igc, +1 on that mail
[10:51] <poolie> vila, testing.txt says it's _test_needs_feature=[...] but that seems wrong
[10:52] <poolie> nm
[10:52] <vila> what is... err
[10:53] <poolie> i was confused
[11:02] <poolie> vila, so you're going to delete the redundant 'requireFeature(Apport..)'
[11:04] <vila> poolie: Yes, I deleted it from your test and keep it only in the deprecation test reproducing the bug
[11:06] <vila> I can delete the all the deprecated features if you want or keep only the ApportFeature one, we have a test covering the CompatibilityFeature thunk anyway,
[11:06] <vila> regarding ApportFeature, I doubt anybody had the opportunity to use it...
[11:08] <Kamping_Kaiser> AIUI, merging a single file into a bzr repo is the same as copying it from its original repo, because bzr only tracks commits, not files. have i got that correct?
[11:09] <Kamping_Kaiser> when i say 'copying' i mean 'cp /this/file ./repo/'
[11:09] <vila> poolie: It http://paste.ubuntu.com/368802/  less magical with that comment ?
[11:09] <vila> s/It/Is/
[11:10] <fullermd> Kamping_Kaiser: I think merge will preserve the file-id, but that's probably the only difference.
[11:11] <Kamping_Kaiser> fullermd: i still have the files original bzr repo in future i can use the file id to track its history by searching in the old bzr repo?
[11:12] <Kamping_Kaiser> *if i
[11:12] <fullermd> Conceptually (though I don't think there's anything in the implementation to automate any of that)
[11:13] <Kamping_Kaiser> hm, ok. its only a few dozen lines of shell, i might just reimpliment it this time. i'll come back and sook when i want something more complex ;)
[12:08] <igc> bialix: please test preference saving in rev 407. bug 516976 ought to be fixed now
[12:11] <bialix> igc: revno 405 don't want to start at all for me. unicode error (again)
[12:11] <igc> bialix: try rev 407
[12:12] <bialix> igc: https://bugs.launchpad.net/bzr-explorer/+bug/517036
[12:13] <bialix> igc: 407 starts but the console full of tracebacks: http://pastebin.com/m57981d80
[12:15] <igc> bialix: delete the tools.xml file in your explorer directory and start the app again please
[12:15] <bialix> https://bugs.launchpad.net/bzr-explorer/+bug/517040
[12:16] <bialix> igc: deleted. now I have unicode error again
[12:16] <igc> bialix: pastebin?
[12:17] <bialix> see it there https://bugs.launchpad.net/bzr-explorer/+bug/517040/comments/1
[12:17] <bialix> igc: ^
[12:18] <bialix> igc: last time it was last month and you decide to move from text to pickle, or something similar
[12:18] <bialix> again: this is bad idea to write localized text to conf files
[12:20] <igc> bialix: well the history file doesn't need to be human readable. explorer.conf does need to be IMO
[12:32] <bialix> igc: https://bugs.launchpad.net/bzr-explorer/+bug/517040/comments/2
[12:35] <bialix> igc: empty toolbars.xml was the raeson of element tree tracebacks
[12:40] <igc> bialix: how did you get an empty toolbars.xml? Maybe that was there once but lib/extensions/__init__.py suggests it should always have content now
[12:41] <bialix> igc: have no idea
[12:41] <bialix> I don't edit anything by hands in explorer/ directory
[12:45] <igc> bialix: I wonder what effort we should make to check bzr vs qbzr vs explorer compatbility?
[12:45] <bialix> what do you mean/
[12:45] <bialix> &
[12:46] <bialix> ?
[12:46] <igc> bialix: I'm seeing quite a few bugs with old explorer and new qbzr or vice versa
[12:46] <bialix> rats
[12:46] <bialix> I'd say in explorer 1.0 you need to force some minimal qbzr version
[12:46] <bialix> I'm ok with this
[12:46] <igc> what's the minimum bzr version for qbzr 0.18?
[12:47] <bialix> there was check in explorer/__init__.py, is not?
[12:47] <bialix> qbzr 0.18 intended to be used with 2.1
[12:47] <bialix> but it should work with 2.0
[12:47] <bialix> I can check, but I don't think we made any special changes in this area
[12:48] <igc> bialix: I can't find that version check. Maybe we moved it?
[12:48] <timour> Hi all, can someone suggest how to disable commit emails in a specific repository?
[12:49] <bialix> igc: perhaps I've confused it with the check in qbzr itself
[12:49] <timour> Specifically, I use etc-keeper with Bazaar, and I don't want commits in etc to be sent to the mailing list of my project.
[12:50] <bialix> timour: do you have enabled mails in bazaar.conf?
[12:50] <bialix> timour: take a look at locations.conf
[12:50] <timour> bialix, yes
[12:50] <bialix> the best place to enable things by directory level is locations.conf
[12:50] <timour> bialix, so this is the config file where one can specify for what local repositories to send commit emails?
[12:51] <bialix> igc: qbzr has check which insist we need bzrlib api >= 1.17
[12:51] <timour> bialix, is this file in .bazaar?
[12:51] <bialix> timour: yes
[12:51] <timour> bialix, thanks a lot!
[12:51] <bialix> check the docs on config files
[12:52] <igc> bialix: what about the progress monitoring changes made in 2.1?
[12:52] <bialix> I don't know
[12:52] <bialix> I did not touch the code, garyvdm too. It seems we don;t support this feature yet
[12:52] <bialix> of course Gary may know better
[12:58] <igc> bialix: I thought garyvdm made some changes following poolie's changes to bzr core. Maybe none were needed?
[12:59] <bialix> I cant say right now
[13:22] <igc> bialix, re bug 517036, please try rev 409
[13:23]  * bialix pulling
[13:24] <bialix> igc: fixed now
[13:24] <bialix> thx
[13:24] <igc> bialix: what does your toolbars.xml file look like?
[13:27] <bialix> igc: now http://pastebin.com/m336afd8a
[13:27] <bialix> I've removed it hour ago, this one created by explorer I suppose
[13:28] <igc> bialix: yes, it will create one if missing
[13:28] <igc> bialix: any other files just creaed there for you?
[13:28] <igc> created
[13:28] <bialix> checking with empty one now
[13:29] <bialix> igc: if the file has size of 0 bytes it's not re-created with valid content then
[13:29] <igc> bialix: right. It was the Unicode Error that was giving your a zero length file though :-(
[13:30] <bialix> igc: http://pastebin.com/d68d7eac5 this is the files created if I remove explorer dir
[13:31] <igc> bialix: that looks good to me
[13:31] <bialix> ok
[13:31] <poolie> hi all
[13:31] <vila> poolie: hey
[13:31] <vila> poolie: It http://paste.ubuntu.com/368802/  less magical with that comment ?
[13:32] <vila> poolie: I said earlier: I can delete the all the deprecated features if you want or keep only the ApportFeature one, we have a test covering the CompatibilityFeature thunk anyway,
[13:33] <vila> regarding ApportFeature, I doubt anybody had the opportunity to use it...
[13:33] <bialix> heya poolie
[13:40] <poolie> vila, a bit less magical
[13:40] <poolie> i was suggesting removing just ApportFetaure
[13:40] <poolie> but either is fine
[13:40] <vila> oh, ok, I'll tweak and merge then
[13:40] <poolie> it was more just a  general comment about not doing too much work in deprecation
[13:41] <poolie> i'll try to read your merge rfc and patch
[13:41] <poolie> not sure when i will get uninterrupted time
[13:41] <vila> poolie: ok, thanks
[13:42] <poolie> yo ucan nag jam or igc
[13:43] <vila> for the conflict handling one ? That's what my last comment was, wasn't it ? :D
[13:43] <vila> oh, silly me, you can't see that, they are CCed
[13:46]  * bialix -> lunch
[13:51] <vila> gorgeous, clicking on the bug link in qlog opens my browser, nice one bialix/garyvdm
[13:54] <bialix> it was luks
[13:55] <bialix> something bad with lp right now
[13:55] <vila> bialix: yup, oopsing all over the place :-/
[13:55]  * bialix goes outside
[13:56] <poolie> srsly?
[13:56] <poolie> vila, which page?
[13:57] <poolie> escalate it if it's persistent
[13:57] <vila> poolie: just checked, mthaddon is restarting apps servers
[13:58] <vila> They oops look like timeouts to me since refreshing succeed half of the time
[14:05] <ddaa> Hello there
[14:06] <ddaa> the rebase plugin works well to rebase to a newer version
[14:06] <ddaa> but I cannot find how to make it rebase to an older version
[14:07] <ddaa> my use case is backporting an independent patch that was committed on a feature branch
[14:07] <ddaa> How can I backport one or several patch while preserving committer, date, etc, like rebase does?
[14:10] <vila> Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.1.0rc1 and 2.0.4 have gone gold
[14:10] <vila> bah
[14:11] <vila> meh, I can't change the topic anymore ? When did that occur ?
[14:18] <poolie> ddaa, sorry, i don't know, it sounds like a bug/limit in bzr-rebase
[14:19] <ddaa> hey poolie
[14:19] <poolie> hi there
[14:20] <poolie> vila, i'm nervous of landing such a large patch to 2.1
[14:20] <poolie> also i can't understand your comment that
[14:20] <poolie> ... oh, i see, you're saying it's too late to add testtools as a dependency
[14:20] <poolie> and it is
[14:21] <vila> yeah, but the patch isn't large, it's only because a lot of code has been moved, but I didn't change the moved code
[14:21] <jelmer> ddaa: bzr replay should be able to do that
[14:21] <poolie> right
[14:22] <ddaa> jelmer: I tried tying that on the command line, and I looked on the bzr plugin guide, http://doc.bazaar.canonical.com/plugins/en/index.html, and I did not see any "bzr replay".
[14:22] <ddaa> oops
[14:22] <vila> poolie: well, I can understand the feeling about SRU, but almost nothing has been changed in the "code" most of the patch is related to the tests
[14:22] <ddaa> actually, it works on the command line
[14:23] <ddaa> jelmer: thanks jelmer, sorry for the noise
[14:23] <jam> morning all
[14:23] <jelmer> ddaa: np
[14:23] <vila> morning jam http://instantrimshot.com/
[14:24] <poolie> vila, did you see igc's mail asking jam to delay the rc?
[14:24] <vila> no :-(
[14:24] <poolie> so i think this should be ok for this too
[14:24] <jam> poolie: well, to do an rc3 today, and to delay final to next week, yes
[14:24] <jam> jelmer: something is wrong with lp:bzr-rewrite
[14:24] <jam> it points to:
[14:24] <jam> https://code.edge.launchpad.net/~jelmer/bzr-rewrite/trunk-mirrorred
[14:24] <jam> which points to http://people.samba.org/bzr/jelmer/bzr-rebase/trunk-mirrorred
[14:24] <jam> but that branch doesn't exist
[14:24] <jam> http://people.samba.org/bzr/jelmer/bzr-rebase/trunk does
[14:24] <poolie> jam, well, specifically after bzr-explorer works
[14:25] <jam> so lp:bzr-rewrite doesn't have 0.5.5 available
[14:25] <poolie> s/works/releases 1.0
[14:25] <poolie> jam/igc "Updated Bazaar 2.1.0 release plane"
[14:26] <poolie> plaan*
[14:26] <poolie> plan*
[14:26] <poolie> laggy connection
[14:26] <fullermd> Hm.  There isn't a bzrtools release to match 2.1 yet either.
[14:26] <jelmer> jam: http://people.samba.org/bzr/jelmer/bzr-rebase/trunk-mirrorred exists here
[14:26] <jam> I'd rather a release plane ...
[14:26] <jam> hmm.. I was spelling it with 1 too few r's :)
[14:27] <jam> however, the launchpad branch is still unhappy
[14:27] <jam> Next Mirror: Disabled
[14:27] <jam> https://code.edge.launchpad.net/~jelmer/bzr-rewrite/trunk-mirrorred
[14:27] <jelmer> I wished launchpad did exponential backoff on failures
[14:27] <poolie> on import failures?
[14:28] <jam> this was a mirror failure
[14:28] <jam> probably had a 1 day outage, and got 5 hiccups in a day
[14:28] <jelmer> poolie: mirror and import failures
[14:29] <jelmer> jam: strangely enough I don't seem to have the authority to reenable the mirror
[14:29] <vila> anybody knows how to change the topic ?
[14:29] <jam> jelmer: neither do I
[14:29] <jam> vila:  /topic ?
[14:29] <poolie> jelmer: you should file a bug for the lack of ability to do that
[14:29] <jam> I use pidgin and just double click
[14:29] <jam> which opens a dialog
[14:29] <poolie> vila, i'll try
[14:29] <poolie> what do you want to add to it?
[14:29] <jam> poolie: he's the PP this week
[14:30] <vila> jam: I tried that but got : #bzr :You're not channel operator
[14:30] <vila> poolie: s/igc/vila/ for pp
[14:30] <jam> vila: I just got the same
[14:30] <jam> that hasn't ever happened before
[14:30] <vila> I was wondering if things have changed because of the recent storms
[14:30] <jam> I wonder who locked down topics to only ops
[14:30] <jam> Looking at the list, I don't think I see any ops ... ?
[14:30] <maxb> I think it might have happened as part of the ircd upgrade
[14:31] <fullermd> Maybe it was just fallout from the ircd change.
[14:31] <vila> -Martinp23- Hi everyone. We've disabled the +S chanmode for the time being. Normally, +S blocks users from joining a channel if they aren't connecting with SSL. If you still see +S in your channel's modelist, it will have *no effect*. For the now, you will be unable to add or remove this mode. We'll have a more permanent resolution asap. We're sorry for the inconvenience caused by our earlier technical difficulties.
[14:32] <vila> on 31/01 1:54
[14:32] <fullermd> Yeah, but it's [probably] the +t that's in effect here.
[14:33] <maxb> yes
[14:33]  * fullermd has a dream that someday there will be an ircd that actually _documents_ all its stuff...
[14:34] <maxb> abentley can op people. lifeless can bestow that ability upon others
[14:35] <vila> maxb: where did you get that info ? 8-)
[14:35] <maxb>  /msg chanserv access #bzr list
[14:36] <maxb>  /msg chanserv help flags  -- for the definitions of the various privilege flags
[14:40] <vila> ok, so someone on the access list just needs to /mode -t
[14:40] <vila> abentley, lifeless: ^
[14:40] <alf__> Hi all, I accidentally pushed a series of revisions to a (local) branch. Is there a way to remove those revisions from the branch?
[14:41] <vila> alf__: push --ovwrwrite
[14:41] <vila> alf__: push --overwrite
[14:41] <vila> grr
[14:41] <jml> poolie, http://robertcorr.com/2010/02/afact-v-iinet/
[14:42] <alf__> vila: What should I push?
[14:43] <vila> alf__: you tell me :D
[14:43] <vila> alf__: the revision you want to be the tip of your remote branch
[14:43] <alf__> vila: Yes ok, let me be more clear :)
[14:44] <vila> alf__: if the branch is local, you can just go there and : bzr pull -r<the_good_one> --overwrite
[14:44]  * vila applauses abentley 
[14:45] <abentley> Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: igc | bzr 2.1.0rc1 and 2.0.4 have gone goldd
[14:45]  * vila applauses abentley 
[14:46] <alf__> vila: Ah, yes that is what I was looking for, thanks!
[14:46] <poolie> hi abentley
[14:46] <bialix> hi jam
[14:46] <abentley> poolie, hi.
[14:57] <gerard_> hey
[14:58] <rubbs> gerard_: hello
[15:00] <gerard_> anyone has some time to review https://code.launchpad.net/~gerard-/bzr/update/+merge/18464 ?
[15:00] <gerard_> vila perhaps?

[15:01] <vila> gerard_: Just got promoted patch pilot, I'm cleaning up the easy bits first and will have a look
[15:01] <vila> gerard_: thanks for your patience
[15:02] <fullermd> poolie: "update --2a"?
[15:03] <vila> fullermd: upgrade ?
[15:03] <fullermd> I dunno which part of it he meant...
[15:03] <gerard_> vila: that's ok
[15:04] <gerard_> I just noticed the unused local "update_dash_r", don't mind that, will remove it tonight
[15:07] <jam> fullermd: I think he actually needs to do 'reconcile' (though just of the branch), but I'm sort of staying away for now
[15:20] <maxb> Yikes. branching a 2a branch locally without stacking or a shared repository feels slower than branching it over the network :-(
[15:56] <doctormo> Hmm, I'm trying to work out why the cmd_revert in builtins is one of the few commands to not accept a directory input.
[15:57] <doctormo> I presume it's because it uses tree_files(..) with default_branch instead
[16:16] <doctormo> how do I use bzr to remove all unknown files?
[16:22] <mzz> doctormo: see "bzr help clean-tree"
[16:31] <doctormo> thanks mzz, worked like a charm
[16:48] <poolie> igc i hope you didn't get up this early for my sake
[16:49] <igc>  poolie: I'm about to grab some sleep actually. Getting up is planned for 6 hours from now :-)
[16:50] <poolie> ok :)
[16:54] <igc> night all
[16:55] <rubbs> night
[16:55] <poolie> night
[17:00] <lifeless> moin moin
[17:19] <jam> lifeless: /wave
[17:19]  * jam away to lunch
[17:19] <mkanat> james_w: You mentioned the other day that it wouldn't be too hard to get *one* point where a revision was merged in. What about getting *all* the points? Does that require graph walking?
[17:20] <lifeless> mkanat: yes
[17:20] <mkanat> Okay.
[17:20] <lifeless> revsions point at parents. merged-in is children
[17:21] <mkanat> Yeah.
[17:21] <mkanat> And merge_sort is the only thing that will tell me where those children show up, right?
[17:22] <lifeless> merge_sort is the sort we use for log
[17:22] <lifeless> if you want revnos you need to use it (directly or indirectly)
[17:23] <vila> lifeless: /wave
[17:24] <vila> lifeless: what kind of dependency should be used for testtools in the bzr package ?
[17:37] <mkanat> lifeless: *nod* And it's also the only built-in way to find out where a revision was merged in, right, other than walking the entire graph myself?
[17:40] <lifeless> vila: arch independent  build depends
[17:40] <lifeless> mkanat: no, there are iterators on branch and so forth
[17:42] <mkanat> Oh, yeah, I see iter_merge_sorted_revisions.
[17:42] <gerard_> hey
[17:54] <gerard_> vila: need any help with the simple stuff?
[19:12] <beuno> http://blog.digital-scurf.org/2010/02/04#comparative-publishing
[19:12] <beuno> \o/
[19:23] <MvG> http://doc.bazaar.canonical.com/bzr.dev/developers/plugin-api.html#metadata-protocol states that bzr_plugin_version should be "a version_info 5-tuple". Does that imply any restrictions on its format? Is there a relation with http://docs.python.org/library/sys.html#sys.version_info ? Not all plugins seem to follow the latter format, is that OK for new plugins as well?
[19:25] <Peng> MvG: The restriction I know of is that it shouldn't make bzrlib._format_version_tuple() throw an exception. :P
[19:28] <MvG> Peng: thx
[20:29] <mwhudson> jelmer: ayt?
[20:51] <maxb> I'm trying to locate the code that is responsible for post_change_branch_tip firing conditional on whether the tip actually changed when doing a "bzr pull", but firing unconditionally with a "bzr pull --overwrite" - can anyone help?
[20:53] <maxb> ah, I think I've found it. GenericInterBranch.update_revisions
[20:58] <mwhudson> mkanat: the revid_to_revno map is definitely not small enough to cache in memory for many branches :(
[20:59] <mkanat> mwhudson: 100,000 revisions, that's going to be...what, maybe 512K of RAM?
[20:59] <mkanat> Well, maybe more.
[20:59] <mkanat> Maybe a few MB.
[21:00] <mwhudson> and loggerhead can examine a few thousand branches...
[21:00] <mkanat> mwhudson: We already are caching it in memory.
[21:00] <mwhudson> mkanat: only 10 at a time
[21:00] <mkanat> mwhudson: Fair enough.
[21:00] <mkanat> mwhudson: But still, we could move the caching to the branch object.
[21:00] <mkanat> mwhudson: And historycache.
[21:01] <mwhudson> mkanat: loggerhead _used_ to cache a lot more in memory, and stopping it doing that helped the memory footprint immensely
[21:01] <mkanat> mwhudson: I can imagine. :-)
[21:01] <mkanat> mwhudson: I'm actually proposing that we cache less than we do now, BTW.
[21:01] <mkanat> (Except my bit about the 100 branches.)
[21:01] <mwhudson> i think using historycache makes a lot of sense though
[21:02] <mwhudson> mkanat: also
[21:02] <mwhudson> I imagine
[21:02] <mwhudson> it'd be fairly safe to use the same branch object across all our
[21:02] <mwhudson> threads.
[21:03] <mwhudson> that sentence doesn't give warm fuzzy thoughts
[21:03] <mkanat> mwhudson: Right, I was wondering about that. :-)
[21:04] <mkanat> mwhudson: One possibility is to put locks around the places that aren't thread-safe.
[21:04] <mkanat> mwhudson: One of the things I'm also trying to accomplish is building the caches lazily.
[21:05] <mkanat> mwhudson: Because, for example, we don't need them at all to display ChangeLogUI, but they're built anyway, because we called History()
[21:05] <Peng> With modern disk formats, how much does Loggerhead still need the caching?
[21:05] <Peng> s/disk/repo/
[21:05] <mwhudson> mkanat: +1 on that
[21:05] <mkanat> Peng: I'm actually not sure.
[21:05] <mwhudson> Peng: sorting the revision graph is still slow
[21:05] <mkanat> Oh, yes, that is needed.
[21:05] <mkanat> I am sure about that.
[21:05] <Peng> How often does it really need the whole revision graph?
[21:05] <mkanat> I did some testing--it takes about 4 seconds to run through iter_merge_sorted_revisions on a loggerhead devel branch.
[21:06] <mkanat> Peng: That's exactly what I just researched.
[21:06] <mkanat> Peng: It only needs it when it has to know where a revision was merged in or from.
[21:06] <mkanat> Peng: So even if we just built the current cache lazily, we'd reduce building that part of the cache to RevisionLogUI and RevisionUI.
[21:08] <mkanat> mwhudson: The only thread-unsafe thing I can imagine about using a branch read-only would be its internal caches.
[21:08] <mkanat> mwhudson: Though of course there could be other things I don't know about.
[21:08] <mwhudson> mkanat: i don't have any specifc worries
[21:08] <Peng> mkanat: <3
[21:08] <mwhudson> mkanat: just general ones :-)
[21:08] <mwhudson> maybe it would be fine
[21:09] <Peng> Yeah, "maybe it would be fine" in regards to thread safety _always_ ends well. ;P
[21:09] <mkanat> mwhudson: Okay. But if we find out that it isn't, instead we can build those three simplified caches that I mentioned on-demand, instead of whenever we instantiate a History.
[21:12] <maxb> What's the most lightweight way to ask bzrlib "Is this specific directory a branch?"
[21:13] <mkanat> maxb: I think Branch.open?
[21:13] <Peng> But that isn't necessarily lightweight, e.g. if it's a branch reference to a remote location, or maybe even a lightweight checkout.
[21:14] <mkanat> maxb: You could check if it has a .bzr first, right?
[21:14] <maxb> yeah, probably not worth that much code
[21:15] <maxb> find_branches is out, because I want not to recurse
[21:15] <mkanat> Yeah. Although I suppose that directory could be a repo, too, if it just has a .bzr in it.
[21:15] <Peng> I've checked for .bzr/branch in the past, but it's evil.
[21:16] <mwhudson> mkanat: yeah
[21:16] <mkanat> Maybe BzrDir.open_branch? I dunnow.
[21:16] <maxb> Ironically the reason I'm caring is because the existing code is finding git repositories that I don't want, since bzr-git is installed :-)
[21:16] <mkanat> mwhudson: Okay. So I'll update the bug with that proposal.
[21:16] <Peng> maxb: :D
[21:17] <Peng> maxb: I'm sure it's possible to work around that, but I dunno how. You can check for some property of foreign branches that doesn't apply to real bzr branches.
[21:19] <Noldorin> hi jelmer
[21:19] <mkanat> mwhudson: With that adjustment, does the rest of the plan sound like what we want to do?
[21:21] <maxb> What's the right API to turn a local pathname into an URL for Branch.open(...) ?
[21:24] <mkanat> maxb: I've always just passed in the local pathname.... :-)
[21:28] <Peng> maxb: IIRC there's something in urlutils, but if passing the local pathname works, just do that.
[21:28] <Peng> If you don't care about errors caused by directories actually called "bzr+ssh" or whatever. :D
[21:34] <mwhudson> urlutils.local_url_to_path
[21:34] <mwhudson> er
[21:35] <mwhudson> *from_path
[22:18] <mkanat> mwhudson: Did you see my question above?
[22:21] <mwhudson> mkanat: i think it sounds reasonable, yes
[22:22] <mkanat> mwhudson: Okay, cool.
[22:27] <knapsack> So my index is corrupt and I'd like to rebuild or repair it.
[22:28] <knapsack> Unfortunately even the results of 'bzr dump-btree' on the indices aren't usable: bzr: ERROR: No such file: u'/home/knapsack/new/.bzr/repository/indices/e5041e9b52c7ccc987767381885f62eb.rix': [Errno 2]
[22:29] <knapsack> Apparently this is referred to in the pack-names file, but doesn't exist. The repository itself is in a Dropbox folder, so may have been modified.
[22:30] <knapsack> The answer at https://answers.launchpad.net/bzr/+question/96346 hasn't helped me, since I can't create any branches.
[22:30] <knapsack> Any way for me to recover from this?
[22:32] <lifeless> perhaps the file is in your dropbox history ?
[22:32] <knapsack> Wow, lessee.
[22:38] <knapsack> That worked.
[22:38] <knapsack> Ever feel kind of embarrassed, but relieved and thankful at the same time?
[22:38] <lifeless> Glad I could help
[22:38] <lifeless> when you're in a crisis outsiders can often offer useful suggestions :)
[22:38] <knapsack> lifeless: Absolutely. Thanks lifeless!
[23:09] <lifeless> spiv: bug 517275 would be lovely to fix for james_w
[23:15] <spiv> lifeless: I'll take a look, sounds like my sort of thing :)
[23:19] <mneptok> ugh. "fragile cleanups" reminds me i need to make a dentist appointment.
[23:24] <lifeless> oh spiv, did I show you testrepository? I think you might have been on leave when I announced it
[23:25] <spiv> lifeless: I think you mentioned it at least, although I haven't taken a look
[23:27] <lifeless> spiv: ok, c ool