[00:38] morning [00:38] hiya [01:02] hi. is there something out there that "plugs in" to something like loggerhead to administer repos/branches/users and whatnot? [01:05] codebrainz: not that I know of [01:05] it might be nice though! perhaps you could file a bug on loggerhead asking for that [01:05] poolie: got a minute for a chat ? [01:05] is loggerhead in python? [01:05] yes [01:05] launchpad.net/loggerhead [01:06] maybe I'll work on a patch [01:06] that would be awesome [01:06] hi there lifeless [01:06] sure [01:14] i think there is already a bug asking for more 'write access' type stuff in loggerhead [01:14] hello [01:15] have any of you previously used git or hg? [01:23] I'm pretty sure everyone here would have tried both [01:24] whysat? [01:25] steven_t: do you have a deeper question trying to get out? [01:25] no. [01:26] ive never learned a vcs before. i want to learn one but want my knowledge to be applicable and useful and relevant for years to come. researching which one to learn :) [01:26] so far git is the winner, because its so modularized and widely supported [01:26] I think they're all very good, myself [01:26] bzr and hg are supposed to be easier to learn, bzr in particular tries to be user friendly [01:27] modularized?! [01:27] steven_t: have you used other vcs's before, like rcs or cvs or svn? [01:28] none. [01:28] the choice in part also depends on whether you're going to be casual or heavy user [01:28] are you familiar with diff and patch? [01:29] no [01:29] i want to become a heavy user, im a coder and plan to be a professional [01:30] what sort of coding and how long have you been coding? [01:30] well technically im already a professional, but what im learning in my spare time is more unixy than my dayjob (cocoa) [01:30] to answer your question: http://blog.degutis.org/post/651422590/i-think-im-a-little-crazy [01:30] git is excessively complex, and rather arcane, IMO. I'd favour bzr or hg, especially if you're without previous VCS knowledge [01:31] what maxb said. [01:31] although without the 'excessively' [01:33] nice read; either bzr or hg would be fine for you [01:33] I'd also consider a code completing editor, although good fast typing skill is always valuable :-) [01:35] django use svn, so you might want to try that first; sometimes the best thing to try is what the people who you work with use [01:35] do you just use one machine mostly? [01:41] poolie: thanks :) [02:39] lifeless: I'm curious as to why pqm is failing. Does it try building the docs via the Makefile? Are there logs I can look at? [02:41] igc: yes, it builds the docs - we check they build on every commit, just like code [02:41] [which is another reason I want all the docs in the one tree, but thats a different discussion] [02:42] igc: its building in a very small chroot, that only has default packages + what we've specifically asked for. We haven't asked for any sphinx stuff, and I don't know what ones to ask for. [02:43] lifeless: we need python-sphinx [02:43] is that the entirety ? [02:43] lifeless: 0.6 or later [02:43] lifeless: I believe so [02:43] hah [02:43] so we're still on hardy [02:43] it has < 0.5.2 [02:43] sorry, <= 0.5.2 [02:43] lifeless: building the PDFs are messier though - LaTeX toolchain [02:44] lifeless: it *may* work there (in terms of building something) [02:44] I'm loathe to disable checking the docs on commit [02:44] i.e. 0.5.2 may be ok [02:44] we've caught doc syntax errors that way [02:45] I'll file an rt [02:45] and we can see what happens. [02:45] lifeless: I agree - let's keep the doc build step as a check [02:46] lifeless, poolie: was there a consensus on https://code.edge.launchpad.net/~ian-clatworthy/bzr/cmds-in-userref-585667/+merge/26004 ? [02:47] igc if it doesn't break the import tests it's ok with me [02:47] igc: I'd be happiest with just calling the register method from the doc generators [02:47] igc: because they are essentially mini front ends, its appropriate that they do that [02:48] igc: this isn't in conflict with poolies comments [02:50] poolie: test_import_tariff passes with my fix fwiw [02:50] then it's ok with me [02:50] its not with me [02:51] if someone later wants to tighten it up while keeping both your test and the import tariffs passing they can [02:51] it will undo work done for commandant [02:51] lifeless: how? [02:52] lifeless: it only uses the builtins if none are already registered afaict [02:52] igc: right, so if none are registered you'll show the bzr specific ones [02:52] lifeless: yes [02:52] which is wrong [02:52] if none are registered, none are registered [02:53] I appreciate that there is a little bit of code tension here, because we have generic and bzr specific stuff in the same module. [02:53] but I really do think its worth having a clear separation [02:54] mm, this code is not super generic at the moment anyhow [02:55] poolie: its used as a generic core by commandant, by lptools, and possibly others [02:56] I thought commandant reimplemented it? [02:56] as jkakar wanted more facilities he decided to layer on us [02:56] I reworked things to make that possible [02:56] Ah ok. [02:57] he has a patch to further reduce stuff in commandant, but that got push back [02:57] and it outside of the commands.py core anyhow, it was about reuseing the cmd_help object and the like [02:57] s/it/is/ [02:58] igc: poolie: What would convince you to keep the query/setting code paths separate? It seems obvious to me that that is desirable, and I'm not sure how to convince you. [02:59] igc: poolie: Its roughly 30 seconds work to add a call to the set function from the doc generator code, so its clearly not about the effort involved :) [02:59] lifeless, i'm pretty sure i made the change that ian's correcting here, not jamu [02:59] poolie: I'm pretty sure I made it [02:59] ah [02:59] lifeless: we don't know how many clients are broken by the change [02:59] poolie: but lets look deeper [03:00] ok [03:00] lifeless: at least the doc generators are broken - they are easily fixed [03:00] poolie: I think you're right, the doc generators already call install_bzr_command_hooks [03:01] ok, land it. [03:01] my complaint is rescinded [03:01] sorry for the noise [03:02] lifeless: I'm not sure the doc generators call install_bzr_command_hooks btw [03:02] igc: see generate_docs.py [03:02] igc: that is the front end, isn't it ? [03:02] lifeless: yep - it is [03:03] igc: it appears to call it [03:03] igc: please do correct me if I'm wrong [03:03] lifeless: you're correct - my mistake [03:05] lifeless: i was looking in the layer below last week (bzrlib/doc_generate) [03:05] so install_bzr_command_hooks is the thing that should be called to make bzr commands visible [03:05] it installes _get_bzr_command [03:05] and _list_bzr_commands [03:06] and if its not enough, then there is a bug [03:06] which is why I've retracted my objection: I was misremembering the function name I needed to care in detail about [03:08] \o/ 247 emails unread, down from 1400 this morning (UDS and moving backlog finally getting under control) [03:08] * igc lunch - bbl [03:53] EODing - started at 6 [06:01] hi [06:01] igc: still here? [06:02] hi bialix! [06:02] hi igc! [06:02] I have a question about bzr-exlorer project [06:02] there is separate documentation for it [06:02] where is the branch? [06:02] bialix: lp:bzr-explorer-website [06:03] igc: I think it's worth to change ownership of this project to bzr-explorer-dev or something similar. what do you think? [06:04] bialix: +1 [06:04] * igc looks [06:04] who is in charge to upload these docs to bazaar site? [06:05] igc: ^ [06:05] bialix: it's done automatically by a cron job ... [06:05] ? [06:06] directly from your branch? [06:06] just make the changes to bzr-explorer-website and it will appear within an hour typically [06:06] from trunk, yes [06:08] so so, branch ownership should be changed to explorer-devs too [06:09] igc: anything other I should be aware of? [06:09] bialix: maybe the bzr-docs team ought to be the maintainer of bzr-explorer-website? [06:09] maybe, I dunno [06:10] igc: there is no bzr-docs team on lp [06:10] ~bzr-doc is [06:11] I'm ok with ~bzr-doc as owner [06:12] igc: when your vacation starts? [06:13] bialix: I'm around this week and next [06:13] bialix: till the 9/Jun at least [06:14] ok [06:15] * bialix has no more questions so far [06:15] thanks igc! [06:17] bialix: fyi, most of the other bzr doc projects are maintained by Bazaar Developers (~bzr) [06:17] bialix: that's a restricted team [06:17] which I'm thinking the owner of bzr-explorer-website ought to be [06:17] otherwise, anyone can "join-up" and spam the site [06:18] bialix: ^^^ [06:19] bialix: is switching ownership to ~bzr ok by you? [06:19] (i.e. ownership of bzr-explorer-website) [06:20] mmm, yes [06:20] but *I* am not memebr of ~bzr [06:20] need to join (again) [06:20] bialix: yes, I just noticed that [06:20] I will do [06:21] bialix: cool (and thanks) [06:23] :-) [06:24] Shucks, after all that time keeping ~bzr bialix-free... [06:24] today is holiday? [06:24] fullermd: yep :-( [06:24] * bialix waves on fullermd [06:25] * igc waves to fullermd too! [06:25] * beuno waves at igc [06:25] hi beuno! [06:25] * fullermd gets a little seasick from all the waving. [06:25] more waves for you: ~~~~~ [06:26] Oooh... urrrg... blech. This must be how Windows developers feel all the time :( [06:28] rotfl [06:28] not really [06:32] bialix: ok - bzr-explorer-website now maintained by ~bzr and trunk moved accordingly [06:32] igc: thanks [06:38] I am getting these gc warning while running some tests. http://pastebin.com/00H7XCn0 ... is this something that I should be worried about? [06:40] this is the test producing the warnings .. http://pastebin.com/KhTkcnV1 [06:44] parthm: yes, that's worth worrying about [06:44] It indicates that some objects have been locked but not unlocked. [06:45] Which is usually a relatively minor issue, but it should be easy to correct (and if it isn't then it suggests a deeper problem) [06:45] spiv: so could this be an issue in test or the code? [06:46] In this case there's nothing in your test method directly that is locking the tree, so I would suspect the code is at fault. [06:46] by test i mean test case. and code is feature. [06:46] spiv: ok. thanks. will check code. [06:50] poolie: thanks! [06:50] hey spiv [06:51] Hey bialix [06:52] is 'self.add_cleanup(tree.lock_read().unlock)' the recommended way now as against try/finally? .. i think the gc issue was due to unlock not being in finally for cmd_ignore. [06:53] i am wondering if i should add_cleanup or try/finally. [06:53] add_cleanup [06:53] There should be something in the dev docs about that [06:54] spiv: ok cool. that was the problem. i will add_cleanup to cmd_ignore. [06:54] spiv: thanks [06:55] Hmm, the docs do mention @only_raises, but don't seem to have been updated to mention bzrlib.cleanup or Command.add_cleanup [06:57] Just quickly, the rationale for preferring add_cleanup is a) it behaves better when multiple exceptions occur, and b) it avoids extremely indented code just because some code needs three different resources acquired and released. [07:00] spiv: that makes sense. thanks. add_cleanup fixed it. [07:54] spiv: quick chat about leaks ? [07:55] spiv: or did you EOD already ? [08:01] hi there vila [08:01] poolie: hey ! [08:05] vila: sure [08:06] spiv: so, regarding our discussion at UDS, I'd like to tweak my description :) The problemS occur when the main thread, close a socket handled by another thread [08:06] spiv: does that make more sense ? [08:08] vila: if you mean 'while another thread is concurrently performing operations on that socket', sure [08:09] spiv: yes, generally listen (Though I avoid that case by faking a connection) or just waiting in a recv() call [08:10] That seems fairly clearly a bad thing to do... does our test suite ever try to do that? [08:10] spiv: so, next, the smart server create a thread for each client connection and make it a daemonic one, errr, push this subject on the stack [08:11] spiv: to reclaim the threads, yes, [08:11] spiv: the server collects the threads as connections occur and in stop_server() calls shutdown(RW) [08:13] the threads are blocked otherwise waiting for the client to speak [08:13] the client sockets are opened, waiting to be used by their respective transport [08:14] we don't have a transport.close() to get out of this loop and I don't want to add it before addressing the leaks [08:16] I will need it anyway as when all leaks are fixed, a full selftest run fails with Too Many Open Files, most of them being transport sockets [08:16] so I first need a way to completely shutdown the server, including all threads, not relying on the daemonic ones anymore [08:18] vila: hmm, so you are saying that it can leak fds if one thread does sock.close() while another thread is doing sock.recv() on the same sock? [08:18] Or are you saying something else? [08:18] the other side of the socket (the client one), [08:19] shutdown() + close() actually (I couldn't find a confirmation that one will call the other) [08:20] So the main thread doing server_sock.close() succesfully closes the server_sock fd and causes the associated thread to terminate, but the client socket is not released too? [08:20] yes [08:20] Ok, that sounds like a bug in our client code to me. [08:20] Possibly in our test infrastructure for our client code. [08:21] spiv: the transport contract says the socket will remain opened so far [08:21] Right. [08:22] and as long as we don't try to manipulate it, there is no point where we can realize it's closed [08:22] The fact the contract doesn't facilitate this doesn't contradict my claim ;) [08:22] I suspect that python can't either so it can't gc it either [08:22] There are a couple of options. [08:23] spiv: I wanted to understand if 'bug in our client code' was covering this [08:23] Well, but in our test infrastructure at least. [08:23] s/but/bug/ [08:24] Whether we decide it's ultimately because the Transport API doesn't provide a way to close connections isn't yet settled in my mind. [08:24] backtracking a bit: 'bad thing to do', yes, but what can be the consequences ? [08:25] So, actually, I think calling close() in one thread while another does recv() is reasonable. [08:25] spiv: no problem with that, as long as the test infra can use it :) [08:25] It's arguably a workaround for a more elegant way to interrupt the worker thread, but in practice it seems to behave the way we'd like it to. [08:25] spiv: knowing that exceptions in threads are caught and re-raised at join time to make it possible to ignore the socket ones occuring in this context [08:26] s/for a/for the absence of a/ [08:26] yup, exactly [08:27] (And glancing at the CPython source for socketmodule.c it seems to be robust enough to make sure the close(fd) really will be called) [08:27] an alternative will be to use timeouts, but I've encountered too many problems with this approach and I'd prefer to avoid it if possible [08:28] I vote very strongly for steering well clear of Python's socket timeouts. [08:28] So there's a fairly cheap thing we could do. [08:28] spiv: but close() itself doesn't ensure the other side is notified right ? There may still be data to be transmitted no ? [08:28] Which is add a hook point that is called every time ConnectedTransport makes a connection [08:29] yeah, I overrided transport.get_transport, same result [08:29] Then the test suite could install a hook function to collect those connection objects, and then close them after every test. [08:29] yeah, addCleanup(disconnect_transport) [08:30] disconnect_transport is an ugly hack so far testing for attributes called 'close' or 'disconnect' :-D [08:31] I think that would a reasonable thing to do. I don't think it would get in the way of possibly adding an official "close connection" API to transport later, and might even be an incremental step towards that. [08:31] It would also be useful as a debugging tool, perhaps. [08:31] exactly, this doesn't address what close connection should mean: always close, close only for the last user of the shared connection, etc [08:32] I could imagine writing a plugin that counts the number of connections, same sort of thing as how -Dhpss etc can report stats about other things. [08:33] hmm, yeah, a hook is better than overriding get_transport in that case, I'll keep that in mind [08:33] And a hook on "create connection" rather than get_transport in general. [08:33] sure [08:34] transports can be created but never connect [08:34] now, about the samrt server itself [08:34] smart [08:34] a daemonic thread is created for each client connection [08:35] this interfere in my leak hunt :) [08:35] most of the test use SmartServer_for_testing, but some don't [08:35] most of the tests use SmartServer_for_testing, but some don't [08:36] I tried to change them but failed, lost in the difference parameters used for __init__ and start_background_thread (from memory) [08:37] Well, why not do the same thing? [08:37] collect threads ? [08:37] Add a hook point to bzrlib.smart.server that is invoked for every new thread? [08:38] There's already an overall server_started (and server_started_ex :/) hook point. [08:38] here you are, thanks, that's the bit I came here for :-) [08:39] a bit more work, but definitely the way to go, hooks are good [08:39] :) [08:40] I think you only need to invoke it from SmartTCPServer.serve_conn [08:40] spiv: a 'connection_started' hook... yes [08:40] Or perhaps from the target func it uses. [08:40] that's the one I override in _for_testing [08:41] may be, I have to do the same kind of stuff for http/sftp anyway, I'll try to unify [08:42] It's not perfect, as the server does occasionally create other threads [08:42] (to handle insert_stream requests) [08:42] But I think probably that it will be good enough. [08:43] vila: btw, jml filed a bug asking about a way to close bzrlib transport connections for launchpad's test suite [08:43] ha ha, thanks for the tip, I still have a few leaks without explanation so far (but nothing critical anymore) [08:44] vila: if you do address this be sure to find that bug and let jml know how we're dealing with a similar problem [08:44] spiv: hehe, I commented there :) Th problem is on my radar for eons, I wanted to address the server side of the problem first to avoid masking it [08:46] success: the gross hack keep the open files to ~50 instead of >1024 ! [08:46] with some fallouts for gio and ftp accounting for ~70 failures but that's expected [08:47] pfew, I see the light ! [08:47] spiv: thanks for the teddy-bearing, very valuable ! [08:48] vila: nice work! Glad I could help :) [08:49] spiv: by the way, bzrlib.smart.server.SmartTCPServer uses a timeout, [08:49] I understand why, yet, it contradicts your recommendation... Why ? [08:49] Because the world is imperfect :( [08:50] grr, I meant: reading the code I understand why you used it, but why take the risk ? [08:50] * spiv looks [08:50] Erk, so it can break out of blocking accept once per second to check if it should stop? Ugh. [08:51] also, isn't there a potential bug there, related to leaks, for a loooong live running smart server ? (Hitting the too many open files limit or something) [08:51] Gosh I wish we could use Twisted for this stuff. [08:51] Not that I know of, why do you think so? [08:51] shooting in the dark here, but in case some weird bug came out of lp, that may be worth looking at [08:52] The leaks we've been discussing are client-side. [08:52] so far yes, I'm now talking about the smart server creating a daemonic thread in serve_conn [08:52] I don't recall any bug reports about 'bzr serve' running out of fds. [08:53] ok, good to know :) [08:53] When the client disconnects that thread will stop. [08:54] hmm, that's the point where I don't know *when* it will stop [08:54] after all, the client leaks in selftest are kind of a mirror scenario [08:55] I do know when it will stop. [08:55] tell me :) [08:56] It will stop when it tries to read from the socket and finds it has been disconnected. [08:56] when will it try to read ? [08:56] All the time, except when actively working on processing bytes it has already received. [08:57] then it will block waiting for the client, what if the client crashed and can't properly close the socket ? [08:57] (and if it is in the middle of calculating a response then that means it's either about to try writing the response, or about to try to read more bytes of the request) [08:58] Well, if the client drops of the internet suddenly and never manages to send a FIN etc then yes the socket will hang around indefinitely. [08:58] guarded by some timeout ? [08:58] I don't think so. Timeouts are a risky proposition. [08:59] no no, not by us, I was thinking by the TCP stack or something [08:59] (Both in that historically Python's socket.settimeout feature has had subtle bugs, and that you can get false positives if the client really does want to be idle for 2 hours) [09:00] Oh, well, some platforms allow you to set a system-wide timeout for checking if a TCP still seems to be alive. [09:00] hmm, ok, out of scope for today and the hook should be far enough for the tests [09:00] But no, we don't do anything about that in bzr. [09:00] It would be good to do so, I think. [09:01] But judging from the lack of bug reports about it I don't think it's a high priority :) [09:01] Yeah, a hook would be handy there, especially if it is passed the thread object and the socket object. [09:01] sure, I wanted to mention the idea in case it would light a bulb for you [09:02] spiv: for my purposes, both are needed :) [09:02] Because then it makes it possible to write a plugin that arranges to e.g. use Linux-only magic to set TCP keepalives per socket. [09:02] vila: great :) [09:04] spiv: just for fun, have a look at bzrlib.tests.stub_sftp.SokectListener for the last biggest source of thread leaks :) [09:05] vila: I've had that fun in the past, I hope you don't mind if I pass on that tonight ;) [09:06] hehe, np, enjoy your evening :) === radoe_ is now known as radoe [09:58] evenin all :) [10:04] hi there [10:21] hi :) [12:03] I'm fairly novice at using bzr and today got stuck with a problem while trying to commit changes to a local branch. bzr just freezes and does nothing... I can run status or log or diff on the same branch, but it hangs when trying to commit the changes done to a single file. Did other commits on the same branch earlier in the day. I know this isn't much to try to help me, but if anyone could point me to some things that is possible to do to tr [12:03] find a bit more about what might be the source of the problem, I would apreciate. [12:03] AntoineLaf: how big is that single file? [12:07] it is a simple settings.php file [12:07] hi. I just filed https://bugs.edge.launchpad.net/bzr-rewrite/+bug/588249 anyone got any ideas? [12:07] Launchpad bug 588249 in bzr-rewrite "[regression] Rebase onto previous revision carries merge-metadata (affected: 1, heat: 0)" [Undecided,New] [12:08] 12kb [12:15] AntoineLaf: in that case, no idea [12:15] AntoineLaf: you might want to try to see what it's stuck on using strace [12:16] jelmer: that's exactly the kind of advice I was looking for :) thx [12:16] now I need to know what strace is... :) [12:17] ah, okey, I see how this could bring some light on the problem. [12:18] tumbleweed: hi [12:18] tumbleweed: what do you mean with "will show merge history" ? [12:19] jelmer: commit 2 is now a merge commit === oubiwann is now known as oubiwann_ [12:19] tumbleweed: of what exactly? [12:19] tumbleweed: also, is this with trunk? [12:19] jelmer: http://paste.ubuntu.com/442742/ [12:19] yes, tested with trunk [12:20] it used to do the right thing, but started doing this a few months ago. I put it down to ineptitude with rebasing until today :) === oubiwann_ is now known as oubiwann [12:28] jelmer: have you got any time to lend a hand in figuring out how to repair https://bugs.launchpad.net/bzr-svn/+bug/587819 ? [12:28] Launchpad bug 587819 in Bazaar Subversion Plugin "race condition when doing a bzr commit to an svn repo (affected: 1, heat: 6)" [Undecided,New] [12:42] tumbleweed: thanks for the bug report [12:42] jelmer: np. glad someone can understand it [12:42] peitschie: sorry, I'm working at the moment [12:42] jelmer: nps. I'm simply under some heavy time constraints... if i can't get the repository repair in the next day we probably will be forced to move back to pure svn [12:43] peitschie: The only real solution is to lock the root of the tree [12:43] jelmer:... obviously not my first preference :) [12:43] jelmer: the pre-commit hook i wrote should prevent it for the interm... it's trying to fix the existing data that is causing issues. I can't create a clean checkout in it's current state [12:46] peitschie: one of the alternatives is to remove all bzr revprops from the later revisions [12:46] that means your history will diverge but you should be able to check out the branch again [12:47] jelmer: sounds like a plan. I'll give that a try and see how badly it fails :) [13:38] jelmer: just to update, removing the bzr revprops really makes a mess of any existing bzr-svn branches (made with the corrupt info). I'll have to see if I can work around it... but this looks like it might be a little too much work to fix :(. that race condition bug really makes a mess! [13:38] thanks for your help though... and the otherwise wonderful plugin :) [13:49] is there something like gitolite/gitosis that exists for bzr? [13:49] csgeek_, what _are_ gitolite or gitosis? [13:50] csgeek_, web frontends? PQMs? ...? [13:51] re the former, I think Loggerhead is preferred [13:51] it allows you to limit what user can write to what using ssh RSA/DSA keys [13:52] ahh [13:52] basically security mechanism for granting user rights to a repo and limit what they can and can't do [13:52] rathern then relying to unix permission. Also prevents users from deleting "master" or whatnot [13:52] see http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/security.html [13:53] thanks nDuff [13:58] csgeek_, ...that said, my preferred route to controlling who has commit where (and under which circumstances they can commit, ie. forcing unit tests / formatting checks / whatnot to pass) is use of a PQM. [14:00] PQM = https://launchpad.net/pqm ? [14:00] csgeek_, and that class of tools, yes; there are a few for git also. [14:01] I'm familiar with the git tools, it has a few shortcomings, at least work preferes bzr (: [14:13] Hi. I started playing around with the externals plugin and navigated myself into a "situation". I first checkout out a svn repo inside m bzr working dir, then added it to .bzrmeta/externals. that broke because the url I used for the svn checkout was different than the one in the externals file (which I noticed on bzr ci), I then deleted the svn checkout and the externals-snapshot file but now I can't commit anymore. bzr ci always gives me: [14:13] bzr: ERROR: Not a branch: "/path/to/bzr/repo/svn/repo" [14:13] bzr st says nothing about that director though, it just shows the removes externals-snapshot [14:13] removed even [14:14] any hints on how to get out of this? [14:19] wow.. so when I make a new branch, that requies a new directory to be created. bzr branch . foobar would branch the current repo to the directory foobar. [14:24] csgeek_, there's an experimental colocated branch support plugin, and proper support should eventually show up in a release. [14:42] * TresEquis finds bzr's non-colocated branches much easier to work with than the git / hg model [14:42] especially with the "shared repository" format [14:45] :) [15:08] garyvdm: re expensive plugins, I bet you're being screwed just by qt import times, it's a big thing [15:08] unless you're already very careful about lazy loading? [15:09] mgz: we are very carefull about lazy loading. [15:10] mgz: it's importing bzrlib.branch [15:11] mgz: but I think the method that I used is not very accurate. :-( [15:12] measuring startup time isn't [15:12] you can do cold startup properly on nix as well, which will give you bigger numbers [15:12] what was the magic drop-caches command again... [15:13] hmm - let me try that [15:14] echo 3>/proc/sys/vm/drop_caches [15:14] after a sync. [15:29] mgz: do you know what I'm doing wrong here? [15:29] http://pastebin.org/ [15:29] http://pastebin.org/298078 [15:36] your shell doesn't seem to support time taking arguments [15:37] (time bzr rocks) 2> plugin_profile.txt [15:37]