[00:05] If I do a bzr pull, will it kill all changes done in this branch and revert it? [00:06] So if there are uncommited changes, or commited changes, they'll all be reverted. [00:08] pull will never discard uncommitted changes. === mzz is now known as mzz_ [00:09] spiv: But it will do away with commited changes? [00:10] If you pull --overwrite to an older revision, then the later revisions will no longer be in that branch's ancestry, yes. [00:10] if they aren't in the new history, yes [00:10] (The revisions will still exist in the repository, though) [00:11] 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] 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] If you did pull in that case, it would tell you 'branches have diverged' [00:12] 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] s/parent directory/parent branch/ [00:13] It's hard to tell what you mean by 'resync' [00:13] Translating bazaar speak into something your holiday developer will understanding is making my terms diverge maxb. [00:14] maxb: ('branches have diverged' is right if we assume the working branch has had commits made, rather than just uncommitted changes) [00:14] a good point [00:15] 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] 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] doctormo: there's "bzr merge --pull", btw, which automates "'bzr pull' if no divergence, otherwise 'bzr merge'" [00:16] 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] doctormo: you can always take a look at the code to see how its implemented. [00:18] doctormo: the code in builtins.py is mostly fairly readable [00:19] spiv: It is, but I'm feeling bad about copying bits out of it, like I'm removing all the checks. [00:19] http://bazaar.launchpad.net/~groundcontrollers/groundcontrol/trunk/annotate/head%3A/GroundControl/bazaar.py [00:20] If interested, look at the do_action methods, I think they probably should be going through builtins. [00:22] doctormo: perhaps you should be reusing some code from the bzr-gtk plugin? [00:22] (or even the qbzr plugin?) [00:23] They've both already wrapped lots of builtin actions into a GUI-friendly form. [00:23] spiv: I already am, as much as I could. But the problem is that I have really bad constraints because of nautilus. [00:23] Ah ok. [00:24] 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] hi all [04:04] hi igc [04:04] hi spiv! [07:37] * spiv finishes up for the day [07:52] poolie: you broke my toy ! https://bugs.edge.launchpad.net/bzr/+bug/516934 [07:52] Ubuntu bug 516934 in bzr "infinite recursion when apport is installed" [Critical,Confirmed] [07:57] Pfft. Your toy is just too slow :p [08:31] * igc dinner === sven is now known as Guest56823 [08:43] hi vila [08:43] hi igc? [08:47] Greetings. Are there any Win32 supporters in - I've just encountered an odd crash that is making me feel panicky [08:48] 'Out of the blue', > bzr explore has stated throwing a MS Visual C++ runtime error. [08:49] Console reports "QVariant::load(QDataStream &s): type list unknown to QVariant." Nothing in .bzr.log [08:51] I presume that's Qt-related. [08:52] 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] Which version? [08:53] (I have no idea what solutions might be BTW, so don't expect answers from me :) [08:53] freshly re-installed bzr2.1.0rc1-1.exe AFTER first hitting the problem [09:00] other tools from the qbzr suite run OK. qlog, qplugins both look normal. [09:01] 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] smartgpx: Don't Panic [09:26] 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] smartgpx: please file a bug against bzr-explorer though better a dupe than no report [09:27] bialix, fullermd : hey guys ! [09:27] Oh, no, go ahead and panic. It's good aerobic exercise. [09:27] heya vila! [09:27] * fullermd waves at vila. [09:27] * vila checks its hitchhiker's guide about aerobic.... [09:28] smartgpx: what's up? [09:28] . 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] NO - I've been told to get my HDL levels down! bialix - summary on Bazaar ML [09:31] HDL? [09:38] High Density Lipids I think - 'Bad Cholesterol'. [09:38] Bugged as Bug#516968 [09:41] Lipoprotein to be precise. [09:41] (and actually HDL is the soi-disant 'good' variant) [09:42] So whoever wants you to get those levels _down_ is... well... are they in your will? ;> [09:42] ubottu: please tell me about bug #516968 [09:42] Launchpad bug 516968 in bzr-explorer "'bzr explore' unexpectedly throwing MS Visual C++ runtime error at startup " [Undecided,New] https://launchpad.net/bugs/516968 [09:43] thank you! [09:44] smartgpx: can you try to remove explorer.conf file? [09:44] or something similar [09:44] fullermd: That should be obvious but how do I make a shell script change my current working directory ? [09:45] 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] CONFIRM that removing explorer.conf gets Explorer running again. [09:45] close explorer, open again and you'll get a crash? [09:46] 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] fullermd: so I have to . shell-script ? [09:46] * fullermd nods. [09:46] rats, . `which shell` args.... how ugly :-/ [09:47] funny I never encounter the problem before... [09:47] Thanks to Simon Kersey for suggesting this. [09:47] Well, maybe you could reach into /proc and manually fudge in the other process's memory. Is that less ugly? ;) [09:47] fullermd: Brilliant ! [09:47] :-P [09:48] Well, naturally. I said it, didn't I? [09:48] smartgpx: perhaps this is because explorer in big flux [09:48] bialix - no, it re-runs OK. I didn't think to mention that I had been exploring the new preferences in r405! [09:48] we need to test how smooth it will upgrade from 0.11.x to 1.0 [09:49] oh, sorry, just saw your mails in bzr ML [09:51] smartgpx: anyway, thanks for testing bleeding edge changes and reporting! [09:56] maybe it isn't a recent problem? Anyway, rebugged as #516976 [09:59] bug #516976 [09:59] Launchpad bug 516976 in bzr-explorer "Saving preferences from Tools/Options inhibits future startup " [Undecided,New] https://launchpad.net/bugs/516976 [09:59] ubottu: pay attention please, when someone says #516976, just interpret it as bug #516976, thanks [09:59] Error: I am only a bot, please don't think I'm intelligent :) [10:00] bialix: faster than me ! [10:00] :-) [10:00] smartgpx: I will try to look on this today [10:01] fullermd: [OT] thanks for making me re-think my knowledge of cholesterol! More reading required. [10:02] Amazing the things version control can lead you to thinking of 8-} [10:08] smartgpx: see my email on the Qt issue [10:22] fullermd: alias is my friend :D alias bzr-review='. `which bzr-review.sh`' [10:26] hi igc :-) [10:32] 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] bialix: understood. On my list for tonight. [10:45] ok [10:45] * bialix working on preparing qbzr 0.18.1 [10:46] anybody seen garyvdm there these days? [10:46] bialix: I'm going to fix bug 516976 asap btw [10:46] Launchpad bug 516976 in bzr-explorer "Saving preferences from Tools/Options inhibits future startup " [Undecided,New] https://launchpad.net/bugs/516976 [10:47] igc: that's will be nice. if you need quick testing ping me [10:47] shall do [10:51] igc, +1 on that mail [10:51] vila, testing.txt says it's _test_needs_feature=[...] but that seems wrong [10:52] nm [10:52] what is... err [10:53] i was confused [11:02] vila, so you're going to delete the redundant 'requireFeature(Apport..)' [11:04] poolie: Yes, I deleted it from your test and keep it only in the deprecation test reproducing the bug [11:06] 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] regarding ApportFeature, I doubt anybody had the opportunity to use it... [11:08] 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] when i say 'copying' i mean 'cp /this/file ./repo/' [11:09] poolie: It http://paste.ubuntu.com/368802/ less magical with that comment ? [11:09] s/It/Is/ [11:10] Kamping_Kaiser: I think merge will preserve the file-id, but that's probably the only difference. [11:11] 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] *if i [11:12] Conceptually (though I don't think there's anything in the implementation to automate any of that) [11:13] 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] bialix: please test preference saving in rev 407. bug 516976 ought to be fixed now [12:08] Launchpad bug 516976 in bzr-explorer "Saving preferences from Tools/Options inhibits future startup " [Undecided,New] https://launchpad.net/bugs/516976 [12:11] igc: revno 405 don't want to start at all for me. unicode error (again) [12:11] bialix: try rev 407 [12:12] igc: https://bugs.launchpad.net/bzr-explorer/+bug/517036 [12:12] Ubuntu bug 517036 in bzr-explorer "explorer revno.405 cant start because of unicode error" [Undecided,New] [12:13] igc: 407 starts but the console full of tracebacks: http://pastebin.com/m57981d80 [12:15] bialix: delete the tools.xml file in your explorer directory and start the app again please [12:15] https://bugs.launchpad.net/bzr-explorer/+bug/517040 [12:15] Ubuntu bug 517040 in bzr-explorer "revno 407 emits a lot of tracebacks to the console" [Undecided,New] [12:16] igc: deleted. now I have unicode error again [12:16] bialix: pastebin? [12:17] see it there https://bugs.launchpad.net/bzr-explorer/+bug/517040/comments/1 [12:17] Ubuntu bug 517040 in bzr-explorer "revno 407 emits a lot of tracebacks to the console" [Undecided,New] [12:17] igc: ^ [12:18] igc: last time it was last month and you decide to move from text to pickle, or something similar [12:18] again: this is bad idea to write localized text to conf files [12:20] bialix: well the history file doesn't need to be human readable. explorer.conf does need to be IMO [12:32] igc: https://bugs.launchpad.net/bzr-explorer/+bug/517040/comments/2 [12:32] Ubuntu bug 517040 in bzr-explorer "revno 407 emits a lot of tracebacks to the console" [Undecided,New] === mrevell is now known as mrevell-lunch [12:35] igc: empty toolbars.xml was the raeson of element tree tracebacks [12:40] 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] igc: have no idea [12:41] I don't edit anything by hands in explorer/ directory [12:45] bialix: I wonder what effort we should make to check bzr vs qbzr vs explorer compatbility? [12:45] what do you mean/ [12:45] & [12:46] ? [12:46] bialix: I'm seeing quite a few bugs with old explorer and new qbzr or vice versa [12:46] rats [12:46] I'd say in explorer 1.0 you need to force some minimal qbzr version [12:46] I'm ok with this [12:46] what's the minimum bzr version for qbzr 0.18? [12:47] there was check in explorer/__init__.py, is not? [12:47] qbzr 0.18 intended to be used with 2.1 [12:47] but it should work with 2.0 [12:47] I can check, but I don't think we made any special changes in this area [12:48] bialix: I can't find that version check. Maybe we moved it? [12:48] Hi all, can someone suggest how to disable commit emails in a specific repository? [12:49] igc: perhaps I've confused it with the check in qbzr itself [12:49] 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] timour: do you have enabled mails in bazaar.conf? [12:50] timour: take a look at locations.conf [12:50] bialix, yes [12:50] the best place to enable things by directory level is locations.conf [12:50] bialix, so this is the config file where one can specify for what local repositories to send commit emails? [12:51] igc: qbzr has check which insist we need bzrlib api >= 1.17 [12:51] bialix, is this file in .bazaar? [12:51] timour: yes [12:51] bialix, thanks a lot! [12:51] check the docs on config files [12:52] bialix: what about the progress monitoring changes made in 2.1? [12:52] I don't know [12:52] I did not touch the code, garyvdm too. It seems we don;t support this feature yet [12:52] of course Gary may know better [12:58] bialix: I thought garyvdm made some changes following poolie's changes to bzr core. Maybe none were needed? [12:59] I cant say right now [13:22] bialix, re bug 517036, please try rev 409 [13:22] Launchpad bug 517036 in bzr-explorer "explorer revno.405 cant start because of unicode error" [Critical,Confirmed] https://launchpad.net/bugs/517036 [13:23] * bialix pulling [13:24] igc: fixed now [13:24] thx [13:24] bialix: what does your toolbars.xml file look like? [13:27] igc: now http://pastebin.com/m336afd8a [13:27] I've removed it hour ago, this one created by explorer I suppose [13:28] bialix: yes, it will create one if missing [13:28] bialix: any other files just creaed there for you? [13:28] created [13:28] checking with empty one now [13:29] igc: if the file has size of 0 bytes it's not re-created with valid content then [13:29] bialix: right. It was the Unicode Error that was giving your a zero length file though :-( [13:30] igc: http://pastebin.com/d68d7eac5 this is the files created if I remove explorer dir [13:31] bialix: that looks good to me [13:31] ok [13:31] hi all [13:31] poolie: hey [13:31] poolie: It http://paste.ubuntu.com/368802/ less magical with that comment ? === mrevell-lunch is now known as mrevell [13:32] 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] regarding ApportFeature, I doubt anybody had the opportunity to use it... [13:33] heya poolie [13:40] vila, a bit less magical [13:40] i was suggesting removing just ApportFetaure [13:40] but either is fine [13:40] oh, ok, I'll tweak and merge then [13:40] it was more just a general comment about not doing too much work in deprecation [13:41] i'll try to read your merge rfc and patch [13:41] not sure when i will get uninterrupted time [13:41] poolie: ok, thanks [13:42] yo ucan nag jam or igc [13:43] for the conflict handling one ? That's what my last comment was, wasn't it ? :D [13:43] oh, silly me, you can't see that, they are CCed [13:46] * bialix -> lunch [13:51] gorgeous, clicking on the bug link in qlog opens my browser, nice one bialix/garyvdm [13:54] it was luks [13:55] something bad with lp right now [13:55] bialix: yup, oopsing all over the place :-/ [13:55] * bialix goes outside [13:56] srsly? [13:56] vila, which page? [13:57] escalate it if it's persistent [13:57] poolie: just checked, mthaddon is restarting apps servers [13:58] They oops look like timeouts to me since refreshing succeed half of the time [14:05] Hello there [14:06] the rebase plugin works well to rebase to a newer version [14:06] but I cannot find how to make it rebase to an older version [14:07] my use case is backporting an independent patch that was committed on a feature branch [14:07] How can I backport one or several patch while preserving committer, date, etc, like rebase does? [14:10] 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] bah [14:11] meh, I can't change the topic anymore ? When did that occur ? [14:18] ddaa, sorry, i don't know, it sounds like a bug/limit in bzr-rebase [14:19] hey poolie [14:19] hi there [14:20] vila, i'm nervous of landing such a large patch to 2.1 [14:20] also i can't understand your comment that [14:20] ... oh, i see, you're saying it's too late to add testtools as a dependency [14:20] and it is [14:21] 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] ddaa: bzr replay should be able to do that [14:21] right [14:22] 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] oops [14:22] 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] actually, it works on the command line [14:23] jelmer: thanks jelmer, sorry for the noise [14:23] morning all [14:23] ddaa: np [14:23] morning jam http://instantrimshot.com/ [14:24] vila, did you see igc's mail asking jam to delay the rc? [14:24] no :-( [14:24] so i think this should be ok for this too [14:24] poolie: well, to do an rc3 today, and to delay final to next week, yes [14:24] jelmer: something is wrong with lp:bzr-rewrite [14:24] it points to: [14:24] https://code.edge.launchpad.net/~jelmer/bzr-rewrite/trunk-mirrorred [14:24] which points to http://people.samba.org/bzr/jelmer/bzr-rebase/trunk-mirrorred [14:24] but that branch doesn't exist [14:24] http://people.samba.org/bzr/jelmer/bzr-rebase/trunk does [14:24] jam, well, specifically after bzr-explorer works [14:25] so lp:bzr-rewrite doesn't have 0.5.5 available [14:25] s/works/releases 1.0 [14:25] jam/igc "Updated Bazaar 2.1.0 release plane" [14:26] plaan* [14:26] plan* [14:26] laggy connection [14:26] Hm. There isn't a bzrtools release to match 2.1 yet either. [14:26] jam: http://people.samba.org/bzr/jelmer/bzr-rebase/trunk-mirrorred exists here [14:26] I'd rather a release plane ... [14:26] hmm.. I was spelling it with 1 too few r's :) [14:27] however, the launchpad branch is still unhappy [14:27] Next Mirror: Disabled [14:27] https://code.edge.launchpad.net/~jelmer/bzr-rewrite/trunk-mirrorred [14:27] I wished launchpad did exponential backoff on failures [14:27] on import failures? [14:28] this was a mirror failure [14:28] probably had a 1 day outage, and got 5 hiccups in a day [14:28] poolie: mirror and import failures [14:29] jam: strangely enough I don't seem to have the authority to reenable the mirror [14:29] anybody knows how to change the topic ? [14:29] jelmer: neither do I [14:29] vila: /topic ? [14:29] jelmer: you should file a bug for the lack of ability to do that [14:29] I use pidgin and just double click [14:29] which opens a dialog [14:29] vila, i'll try [14:29] what do you want to add to it? [14:29] poolie: he's the PP this week [14:30] jam: I tried that but got : #bzr :You're not channel operator [14:30] poolie: s/igc/vila/ for pp [14:30] vila: I just got the same [14:30] that hasn't ever happened before [14:30] I was wondering if things have changed because of the recent storms [14:30] I wonder who locked down topics to only ops [14:30] Looking at the list, I don't think I see any ops ... ? [14:30] I think it might have happened as part of the ircd upgrade [14:31] Maybe it was just fallout from the ircd change. [14:31] -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] on 31/01 1:54 [14:32] Yeah, but it's [probably] the +t that's in effect here. [14:33] yes [14:33] * fullermd has a dream that someday there will be an ircd that actually _documents_ all its stuff... [14:34] abentley can op people. lifeless can bestow that ability upon others [14:35] maxb: where did you get that info ? 8-) [14:35] /msg chanserv access #bzr list [14:36] /msg chanserv help flags -- for the definitions of the various privilege flags [14:40] ok, so someone on the access list just needs to /mode -t [14:40] abentley, lifeless: ^ [14:40] 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] alf__: push --ovwrwrite [14:41] alf__: push --overwrite [14:41] grr [14:41] poolie, http://robertcorr.com/2010/02/afact-v-iinet/ [14:42] vila: What should I push? [14:43] alf__: you tell me :D [14:43] alf__: the revision you want to be the tip of your remote branch [14:43] vila: Yes ok, let me be more clear :) [14:44] alf__: if the branch is local, you can just go there and : bzr pull -r --overwrite [14:44] * vila applauses abentley [14:45] 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 === abentley changed the topic of #bzr to: 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 === abentley changed the topic of #bzr to: 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 gold === vila changed the topic of #bzr to: 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:46] vila: Ah, yes that is what I was looking for, thanks! [14:46] hi abentley [14:46] hi jam [14:46] poolie, hi. === salgado is now known as salgado-lunch [14:57] hey [14:58] gerard_: hello [15:00] anyone has some time to review https://code.launchpad.net/~gerard-/bzr/update/+merge/18464 ? [15:00] vila perhaps? [15:00] [15:01] gerard_: Just got promoted patch pilot, I'm cleaning up the easy bits first and will have a look [15:01] gerard_: thanks for your patience [15:02] poolie: "update --2a"? [15:03] fullermd: upgrade ? [15:03] I dunno which part of it he meant... [15:03] vila: that's ok [15:04] I just noticed the unused local "update_dash_r", don't mind that, will remove it tonight [15:07] 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] Yikes. branching a 2a branch locally without stacking or a shared repository feels slower than branching it over the network :-( [15:56] 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] I presume it's because it uses tree_files(..) with default_branch instead === salgado-lunch is now known as salgado [16:16] how do I use bzr to remove all unknown files? [16:22] doctormo: see "bzr help clean-tree" [16:31] thanks mzz, worked like a charm === gerard_ is now known as gerard_work_away [16:48] igc i hope you didn't get up this early for my sake [16:49] poolie: I'm about to grab some sleep actually. Getting up is planned for 6 hours from now :-) [16:50] ok :) [16:54] night all [16:55] night [16:55] night [17:00] moin moin [17:19] lifeless: /wave [17:19] * jam away to lunch [17:19] 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] mkanat: yes [17:20] Okay. [17:20] revsions point at parents. merged-in is children [17:21] Yeah. [17:21] And merge_sort is the only thing that will tell me where those children show up, right? [17:22] merge_sort is the sort we use for log [17:22] if you want revnos you need to use it (directly or indirectly) [17:23] lifeless: /wave [17:24] lifeless: what kind of dependency should be used for testtools in the bzr package ? [17:37] 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] vila: arch independent build depends [17:40] mkanat: no, there are iterators on branch and so forth [17:42] Oh, yeah, I see iter_merge_sorted_revisions. [17:42] hey [17:54] vila: need any help with the simple stuff? [19:12] http://blog.digital-scurf.org/2010/02/04#comparative-publishing [19:12] \o/ [19:23] 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] MvG: The restriction I know of is that it shouldn't make bzrlib._format_version_tuple() throw an exception. :P [19:28] Peng: thx === salgado is now known as salgado-afk [20:29] jelmer: ayt? [20:51] 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] ah, I think I've found it. GenericInterBranch.update_revisions [20:58] mkanat: the revid_to_revno map is definitely not small enough to cache in memory for many branches :( [20:59] mwhudson: 100,000 revisions, that's going to be...what, maybe 512K of RAM? [20:59] Well, maybe more. [20:59] Maybe a few MB. [21:00] and loggerhead can examine a few thousand branches... [21:00] mwhudson: We already are caching it in memory. [21:00] mkanat: only 10 at a time [21:00] mwhudson: Fair enough. [21:00] mwhudson: But still, we could move the caching to the branch object. [21:00] mwhudson: And historycache. [21:01] mkanat: loggerhead _used_ to cache a lot more in memory, and stopping it doing that helped the memory footprint immensely [21:01] mwhudson: I can imagine. :-) [21:01] mwhudson: I'm actually proposing that we cache less than we do now, BTW. [21:01] (Except my bit about the 100 branches.) [21:01] i think using historycache makes a lot of sense though [21:02] mkanat: also [21:02] I imagine [21:02] it'd be fairly safe to use the same branch object across all our [21:02] threads. [21:03] that sentence doesn't give warm fuzzy thoughts [21:03] mwhudson: Right, I was wondering about that. :-) [21:04] mwhudson: One possibility is to put locks around the places that aren't thread-safe. [21:04] mwhudson: One of the things I'm also trying to accomplish is building the caches lazily. [21:05] 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]