[00:38] <igc> morning
[00:38] <lifeless> hiya
[01:02] <codebrainz> hi.  is there something out there that "plugs in" to something like loggerhead to administer repos/branches/users and whatnot?
[01:05] <lifeless> codebrainz: not that I know of
[01:05] <lifeless> it might be nice though! perhaps you could file a bug on loggerhead asking for that
[01:05] <lifeless> poolie: got a minute for a chat ?
[01:05] <codebrainz> is loggerhead in python?
[01:05] <lifeless> yes
[01:05] <lifeless> launchpad.net/loggerhead
[01:06] <codebrainz> maybe I'll work on a patch
[01:06] <lifeless> that would be awesome
[01:06] <poolie> hi there lifeless
[01:06] <poolie> sure
[01:14] <mwhudson> i think there is already a bug asking for more 'write access' type stuff in loggerhead
[01:14] <steven_t> hello
[01:15] <steven_t> have any of you previously used git or hg?
[01:23] <mlh> I'm pretty sure everyone here would have tried both
[01:24] <steven_t> whysat?
[01:25] <mlh> steven_t: do you have a deeper question trying to get out?
[01:25] <steven_t> no.
[01:26] <steven_t> 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] <steven_t> so far git is the winner, because its so modularized and widely supported
[01:26] <mlh> I think they're all very good, myself
[01:26] <mlh> bzr and hg are supposed to be easier to learn, bzr in particular tries to be user friendly
[01:27] <maxb> modularized?!
[01:27] <mlh> steven_t: have you used other vcs's before, like rcs or cvs or svn?
[01:28] <steven_t> none.
[01:28] <mlh> the choice in part also depends on whether you're going to be casual or heavy user
[01:28] <mlh> are you familiar with diff and patch?
[01:29] <steven_t> no
[01:29] <steven_t> i want to become a heavy user, im a coder and plan to be a professional
[01:30] <mlh> what sort of coding and how long have you been coding?
[01:30] <steven_t> well technically im already a professional, but what im learning in my spare time is more unixy than my dayjob (cocoa)
[01:30] <steven_t> to answer your question: http://blog.degutis.org/post/651422590/i-think-im-a-little-crazy
[01:30] <maxb> git is excessively complex, and rather arcane, IMO. I'd favour bzr or hg, especially if you're without previous VCS knowledge
[01:31] <mlh> what maxb said.
[01:31] <mlh> although without the 'excessively'
[01:33] <mlh> nice read; either bzr or hg would be fine for you
[01:33] <mlh> I'd also consider a code completing editor, although good fast typing skill is always valuable :-)
[01:35] <mlh> 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] <mlh> do you just use one machine mostly?
[01:41] <lifeless> poolie: thanks :)
[02:39] <igc> 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] <lifeless> igc: yes, it builds the docs - we check they build on every commit, just like code
[02:41] <lifeless> [which is another reason I want all the docs in the one tree, but thats a different discussion]
[02:42] <lifeless> 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] <igc> lifeless: we need python-sphinx
[02:43] <lifeless> is that the entirety ?
[02:43] <igc> lifeless: 0.6 or later
[02:43] <igc> lifeless: I believe so
[02:43] <lifeless> hah
[02:43] <lifeless> so we're still on hardy
[02:43] <lifeless> it has < 0.5.2
[02:43] <lifeless> sorry, <= 0.5.2
[02:43] <igc> lifeless: building the PDFs are messier though - LaTeX toolchain
[02:44] <igc> lifeless: it *may* work there (in terms of building something)
[02:44] <lifeless> I'm loathe to disable checking the docs on commit
[02:44] <igc> i.e. 0.5.2 may be ok
[02:44] <lifeless> we've caught doc syntax errors that way
[02:45] <lifeless> I'll file an rt
[02:45] <lifeless> and we can see what happens.
[02:45] <igc> lifeless: I agree - let's keep the doc build step as a check
[02:46] <igc> lifeless, poolie: was there a consensus on https://code.edge.launchpad.net/~ian-clatworthy/bzr/cmds-in-userref-585667/+merge/26004 ?
[02:47] <poolie> igc if it doesn't break the import tests it's ok with me
[02:47] <lifeless> igc: I'd be happiest with just calling the register method from the doc generators
[02:47] <lifeless> igc: because they are essentially mini front ends, its appropriate that they do that
[02:48] <lifeless> igc: this isn't in conflict with poolies comments
[02:50] <igc> poolie: test_import_tariff passes with my fix fwiw
[02:50] <poolie> then it's ok with me
[02:50] <lifeless> its not with me
[02:51] <poolie> if someone later wants to tighten it up while keeping both your test and the import tariffs passing they can
[02:51] <lifeless> it will undo work done for commandant
[02:51] <igc> lifeless: how?
[02:52] <igc> lifeless: it only uses the builtins if none are already registered afaict
[02:52] <lifeless> igc: right, so if none are registered you'll show the bzr specific ones
[02:52] <igc> lifeless: yes
[02:52] <lifeless> which is wrong
[02:52] <lifeless> if none are registered, none are registered
[02:53] <lifeless> 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] <lifeless> but I really do think its worth having a clear separation
[02:54] <poolie> mm, this code is not super generic at the moment anyhow
[02:55] <lifeless> poolie: its used as a generic core by commandant, by lptools, and possibly others
[02:56] <spiv> I thought commandant reimplemented it?
[02:56] <lifeless> as jkakar wanted more facilities he decided to layer on us
[02:56] <lifeless> I reworked things to make that possible
[02:56] <spiv> Ah ok.
[02:57] <lifeless> he has a patch to further reduce stuff in commandant, but that got push back
[02:57] <lifeless> and it outside of the commands.py core anyhow, it was about reuseing the cmd_help object and the like
[02:57] <lifeless> s/it/is/
[02:58] <lifeless> 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] <lifeless> 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] <poolie> lifeless, i'm pretty sure i made the change that ian's correcting here, not jamu
[02:59] <lifeless> poolie: I'm pretty sure I made it
[02:59] <poolie> ah
[02:59] <igc> lifeless: we don't know how many clients are broken by the change
[02:59] <lifeless> poolie: but lets look deeper
[03:00] <lifeless> ok
[03:00] <igc> lifeless: at least the doc generators are broken - they are easily fixed
[03:00] <lifeless> poolie: I think you're right, the doc generators already call install_bzr_command_hooks
[03:01] <lifeless> ok, land it.
[03:01] <lifeless> my complaint is rescinded
[03:01] <lifeless> sorry for the noise
[03:02] <igc> lifeless: I'm not sure the doc generators call install_bzr_command_hooks btw
[03:02] <lifeless> igc: see generate_docs.py
[03:02] <lifeless> igc: that is the front end, isn't it ?
[03:02] <igc> lifeless: yep - it is
[03:03] <lifeless> igc: it appears to call it
[03:03] <lifeless> igc: please do correct me if I'm wrong
[03:03] <igc> lifeless: you're correct - my mistake
[03:05] <igc> lifeless: i was looking in the layer below last week (bzrlib/doc_generate)
[03:05] <lifeless> so install_bzr_command_hooks is the thing that should be called to make bzr commands visible
[03:05] <lifeless> it installes _get_bzr_command
[03:05] <lifeless> and _list_bzr_commands
[03:06] <lifeless> and if its not enough, then there is a bug
[03:06] <lifeless> which is why I've retracted my objection: I was misremembering the function name I needed to care in detail about
[03:08] <lifeless> \o/ 247 emails unread, down from 1400 this morning (UDS and moving backlog finally getting under control)
[03:08]  * igc lunch - bbl
[03:53] <lifeless> EODing - started at 6
[06:01] <bialix> hi
[06:01] <bialix> igc: still here?
[06:02] <igc> hi bialix!
[06:02] <bialix> hi igc!
[06:02] <bialix> I have a question about bzr-exlorer project
[06:02] <bialix> there is separate documentation for it
[06:02] <bialix> where is the branch?
[06:02] <igc> bialix: lp:bzr-explorer-website
[06:03] <bialix> 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] <igc> bialix: +1
[06:04]  * igc looks
[06:04] <bialix> who is in charge to upload these docs to bazaar site?
[06:05] <bialix> igc: ^
[06:05] <igc> bialix: it's done automatically by a cron job ...
[06:05] <bialix> ?
[06:06] <bialix> directly from your branch?
[06:06] <igc> just make the changes to bzr-explorer-website and it will appear within an hour typically
[06:06] <igc> from trunk, yes
[06:08] <bialix> so so, branch ownership should be changed to explorer-devs too
[06:09] <bialix> igc: anything other I should be aware of?
[06:09] <igc> bialix: maybe the bzr-docs team ought to be the maintainer of bzr-explorer-website?
[06:09] <bialix> maybe, I dunno
[06:10] <bialix> igc: there is no bzr-docs team on lp
[06:10] <bialix> ~bzr-doc is
[06:11] <bialix> I'm ok with ~bzr-doc as owner
[06:12] <bialix> igc: when your vacation starts?
[06:13] <igc> bialix: I'm around this week and next
[06:13] <igc> bialix: till the 9/Jun at least
[06:14] <bialix> ok
[06:15]  * bialix has no more questions so far
[06:15] <bialix> thanks igc!
[06:17] <igc> bialix: fyi, most of the other bzr doc projects are maintained by Bazaar Developers (~bzr)
[06:17] <igc> bialix: that's a restricted team
[06:17] <igc> which I'm thinking the owner of bzr-explorer-website ought to be
[06:17] <igc> otherwise, anyone can "join-up" and spam the site
[06:18] <igc> bialix: ^^^
[06:19] <igc> bialix: is switching ownership to ~bzr ok by you?
[06:19] <igc> (i.e. ownership of bzr-explorer-website)
[06:20] <bialix> mmm, yes
[06:20] <bialix> but *I* am not memebr of ~bzr
[06:20] <bialix> need to join (again)
[06:20] <igc> bialix: yes, I just noticed that
[06:20] <bialix> I will do
[06:21] <igc> bialix: cool (and thanks)
[06:23] <bialix> :-)
[06:24] <fullermd> Shucks, after all that time keeping ~bzr bialix-free...
[06:24] <bialix> today is holiday?
[06:24] <bialix> fullermd: yep :-(
[06:24]  * bialix waves on fullermd
[06:25]  * igc waves to fullermd too!
[06:25]  * beuno waves at igc 
[06:25] <igc> hi beuno!
[06:25]  * fullermd gets a little seasick from all the waving.
[06:25] <bialix> more waves for you: ~~~~~
[06:26] <fullermd> Oooh...  urrrg...   blech.  This must be how Windows developers feel all the time   :(
[06:28] <bialix> rotfl
[06:28] <bialix> not really
[06:32] <igc> bialix: ok - bzr-explorer-website now maintained by ~bzr and trunk moved accordingly
[06:32] <bialix> igc: thanks
[06:38] <parthm> 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] <parthm> this is the test producing the warnings .. http://pastebin.com/KhTkcnV1
[06:44] <spiv> parthm: yes, that's worth worrying about
[06:44] <spiv> It indicates that some objects have been locked but not unlocked.
[06:45] <spiv> 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] <parthm> spiv: so could this be an issue in test or the code?
[06:46] <spiv> 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] <parthm> by test i mean test case. and code is feature.
[06:46] <parthm> spiv: ok. thanks. will check code.
[06:50] <bialix> poolie: thanks!
[06:50] <bialix> hey spiv
[06:51] <spiv> Hey bialix
[06:52] <parthm> 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] <parthm> i am wondering if i should add_cleanup or try/finally.
[06:53] <spiv> add_cleanup
[06:53] <spiv> There should be something in the dev docs about that
[06:54] <parthm> spiv: ok cool. that was the problem. i will add_cleanup to cmd_ignore.
[06:54] <parthm> spiv: thanks
[06:55] <spiv> 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] <spiv> 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] <parthm> spiv: that makes sense. thanks. add_cleanup fixed it.
[07:54] <vila> spiv: quick chat about leaks ?
[07:55] <vila> spiv: or did you EOD already ?
[08:01] <poolie> hi there vila
[08:01] <vila> poolie: hey !
[08:05] <spiv> vila: sure
[08:06] <vila> 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] <vila> spiv: does that make more sense ?
[08:08] <spiv> vila: if you mean 'while another thread is concurrently performing operations on that socket', sure
[08:09] <vila> spiv: yes, generally listen (Though I avoid that case by faking a connection) or just waiting in a recv() call
[08:10] <spiv> That seems fairly clearly a bad thing to do... does our test suite ever try to do that?
[08:10] <vila> 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] <vila> spiv: to reclaim the threads, yes,
[08:11] <vila> spiv: the server collects the threads as connections occur and in stop_server() calls shutdown(RW)
[08:13] <vila> the threads are blocked otherwise waiting for the client to speak
[08:13] <vila> the client sockets are opened, waiting to be used by their respective transport
[08:14] <vila> 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] <vila> 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] <vila> so I first need a way to completely shutdown the server, including all threads, not relying on the daemonic ones anymore
[08:18] <spiv> 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] <spiv> Or are you saying something else?
[08:18] <vila> the other side of the socket (the client one),
[08:19] <vila> shutdown() + close() actually (I couldn't find a confirmation that one will call the other)
[08:20] <spiv> 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] <vila> yes
[08:20] <spiv> Ok, that sounds like a bug in our client code to me.
[08:20] <spiv> Possibly in our test infrastructure for our client code.
[08:21] <vila> spiv: the transport contract says the socket will remain opened so far
[08:21] <spiv> Right.
[08:22] <vila> and as long as we don't try to manipulate it, there is no point where we can realize it's closed
[08:22] <spiv> The fact the contract doesn't facilitate this doesn't contradict my claim ;)
[08:22] <vila> I suspect that python can't either so it can't gc it either
[08:22] <spiv> There are a couple of options.
[08:23] <vila> spiv: I wanted to understand if 'bug in our client code' was covering this
[08:23] <spiv> Well, but in our test infrastructure at least.
[08:23] <spiv> s/but/bug/
[08:24] <spiv> 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] <vila> backtracking a bit: 'bad thing to do', yes, but what can be the consequences ?
[08:25] <spiv> So, actually, I think calling close() in one thread while another does recv() is reasonable.
[08:25] <vila> spiv: no problem with that, as long as the test infra can use it :)
[08:25] <spiv> 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] <vila> 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] <spiv> s/for a/for the absence of a/
[08:26] <vila> yup, exactly
[08:27] <spiv> (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] <vila> 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] <spiv> I vote very strongly for steering well clear of Python's socket timeouts.
[08:28] <spiv> So there's a fairly cheap thing we could do.
[08:28] <vila> spiv: but close() itself doesn't ensure the other side is notified right ? There may still be data to be transmitted no ?
[08:28] <spiv> Which is add a hook point that is called every time ConnectedTransport makes a connection
[08:29] <vila> yeah, I overrided transport.get_transport, same result
[08:29] <spiv> Then the test suite could install a hook function to collect those connection objects, and then close them after every test.
[08:29] <vila> yeah, addCleanup(disconnect_transport)
[08:30] <vila> disconnect_transport is an ugly hack so far testing for attributes called 'close' or 'disconnect' :-D
[08:31] <spiv> 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] <spiv> It would also be useful as a debugging tool, perhaps.
[08:31] <vila> 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] <spiv> 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] <vila> hmm, yeah, a hook is better than overriding get_transport in that case, I'll keep that in mind
[08:33] <spiv> And a hook on "create connection" rather than get_transport in general.
[08:33] <vila> sure
[08:34] <vila> transports can be created but never connect
[08:34] <vila> now, about the samrt server itself
[08:34] <vila> smart
[08:34] <vila> a daemonic thread is created for each client connection
[08:35] <vila> this interfere in my leak hunt :)
[08:35] <vila> most of the test use SmartServer_for_testing, but some don't
[08:35] <vila> most of the tests use SmartServer_for_testing, but some don't
[08:36] <vila> I tried to change them but failed, lost in the difference parameters used for __init__ and start_background_thread (from memory)
[08:37] <spiv> Well, why not do the same thing?
[08:37] <vila> collect threads ?
[08:37] <spiv> Add a hook point to bzrlib.smart.server that is invoked for every new thread?
[08:38] <spiv> There's already an overall server_started (and server_started_ex :/) hook point.
[08:38] <vila> here you are, thanks, that's the bit I came here for :-)
[08:39] <vila> a bit more work, but definitely the way to go, hooks are good
[08:39] <vila> :)
[08:40] <spiv> I think you only need to invoke it from SmartTCPServer.serve_conn
[08:40] <vila> spiv: a 'connection_started' hook... yes
[08:40] <spiv> Or perhaps from the target func it uses.
[08:40] <vila> that's the one I override in _for_testing
[08:41] <vila> may be, I have to do the same kind of stuff for http/sftp anyway, I'll try to unify
[08:42] <spiv> It's not perfect, as the server does occasionally create other threads
[08:42] <spiv> (to handle insert_stream requests)
[08:42] <spiv> But I think probably that it will be good enough.
[08:43] <spiv> vila: btw, jml filed a bug asking about a way to close bzrlib transport connections for launchpad's test suite
[08:43] <vila> ha ha, thanks for the tip, I still have a few leaks without explanation so far (but nothing critical anymore)
[08:44] <spiv> 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] <vila> 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] <vila> success: the gross hack keep the open files to ~50 instead of >1024 !
[08:46] <vila> with some fallouts for gio and ftp accounting for ~70 failures but that's expected
[08:47] <vila> pfew, I see the light !
[08:47] <vila> spiv: thanks for the teddy-bearing, very valuable !
[08:48] <spiv> vila: nice work!  Glad I could help :)
[08:49] <vila> spiv: by the way, bzrlib.smart.server.SmartTCPServer uses a timeout,
[08:49] <vila> I understand why, yet, it contradicts your recommendation... Why ?
[08:49] <spiv> Because the world is imperfect :(
[08:50] <vila> grr, I meant: reading the code I understand why you used it, but why take the risk ?
[08:50]  * spiv looks
[08:50] <spiv> Erk, so it can break out of blocking accept once per second to check if it should stop?  Ugh.
[08:51] <vila> 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] <spiv> Gosh I wish we could use Twisted for this stuff.
[08:51] <spiv> Not that I know of, why do you think so?
[08:51] <vila> shooting in the dark here, but in case some weird bug came out of lp, that may be worth looking at
[08:52] <spiv> The leaks we've been discussing are client-side.
[08:52] <vila> so far yes, I'm now talking about the smart server creating a daemonic thread in serve_conn
[08:52] <spiv> I don't recall any bug reports about 'bzr serve' running out of fds.
[08:53] <vila> ok, good to know :)
[08:53] <spiv> When the client disconnects that thread will stop.
[08:54] <vila> hmm, that's the point where I don't know *when* it will stop
[08:54] <vila> after all, the client leaks in selftest are kind of a mirror scenario
[08:55] <spiv> I do know when it will stop.
[08:55] <vila> tell me :)
[08:56] <spiv> It will stop when it tries to read from the socket and finds it has been disconnected.
[08:56] <vila> when will it try to read ?
[08:56] <spiv> All the time, except when actively working on processing bytes it has already received.
[08:57] <vila> then it will block waiting for the client, what if the client crashed  and can't properly close the socket ?
[08:57] <spiv> (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] <spiv> 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] <vila> guarded by some timeout ?
[08:58] <spiv> I don't think so.  Timeouts are a risky proposition.
[08:59] <vila> no no, not by us, I was thinking by the TCP stack or something
[08:59] <spiv> (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] <spiv> Oh, well, some platforms allow you to set a system-wide timeout for checking if a TCP still seems to be alive.
[09:00] <vila> hmm, ok, out of scope for today and the hook should be far enough for the tests
[09:00] <spiv> But no, we don't do anything about that in bzr.
[09:00] <spiv> It would be good to do so, I think.
[09:01] <spiv> But judging from the lack of bug reports about it I don't think it's a high priority :)
[09:01] <spiv> Yeah, a hook would be handy there, especially if it is passed the thread object and the socket object.
[09:01] <vila> sure, I wanted to mention the idea in case it would light a bulb for you
[09:02] <vila> spiv: for my purposes, both are needed :)
[09:02] <spiv> 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] <spiv> vila: great :)
[09:04] <vila> spiv: just for fun, have  a look at bzrlib.tests.stub_sftp.SokectListener for the last biggest source of thread leaks :)
[09:05] <spiv> vila: I've had that fun in the past, I hope you don't mind if I pass on that tonight ;)
[09:06] <vila> hehe, np, enjoy your evening :)
[09:58] <peitschie> evenin all :)
[10:04] <poolie> hi there
[10:21] <peitschie> hi :)
[12:03] <AntoineLaf> 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] <AntoineLaf> find a bit more about what might be the source of the problem, I would apreciate.
[12:03] <jelmer> AntoineLaf: how big is that single file?
[12:07] <AntoineLaf> it is a simple settings.php file
[12:07] <tumbleweed> hi. I just filed https://bugs.edge.launchpad.net/bzr-rewrite/+bug/588249 anyone got any ideas?
[12:08] <AntoineLaf> 12kb
[12:15] <jelmer> AntoineLaf: in that case, no idea
[12:15] <jelmer> AntoineLaf: you might want to try to see what it's stuck on using strace
[12:16] <AntoineLaf> jelmer: that's exactly the kind of advice I was looking for :) thx
[12:16] <AntoineLaf> now I need to know what strace is... :)
[12:17] <AntoineLaf> ah, okey, I see how this could bring some light on the problem.
[12:18] <jelmer> tumbleweed: hi
[12:18] <jelmer> tumbleweed: what do you mean with "will show merge history" ?
[12:19] <tumbleweed> jelmer: commit 2 is now a merge commit
[12:19] <jelmer> tumbleweed: of what exactly?
[12:19] <jelmer> tumbleweed: also, is this with trunk?
[12:19] <tumbleweed> jelmer: http://paste.ubuntu.com/442742/
[12:19] <tumbleweed> yes, tested with trunk
[12:20] <tumbleweed> 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 :)
[12:28] <peitschie> 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:42] <jelmer> tumbleweed: thanks for the bug report
[12:42] <tumbleweed> jelmer: np. glad someone can understand it
[12:42] <jelmer> peitschie: sorry, I'm working at the moment
[12:42] <peitschie> 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] <jelmer> peitschie: The only real solution is to lock the root of the tree
[12:43] <peitschie> jelmer:... obviously not my first preference :)
[12:43] <peitschie> 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] <jelmer> peitschie: one of the alternatives is to remove all bzr revprops from the later revisions
[12:46] <jelmer> that means your history will diverge but you should be able to check out the branch again
[12:47] <peitschie> jelmer:  sounds like a plan.  I'll give that a try and see how badly it fails :)
[13:38] <peitschie> 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] <peitschie> thanks for your help though... and the otherwise wonderful plugin :)
[13:49] <csgeek_> is there something like gitolite/gitosis that exists for bzr?
[13:49] <nDuff> csgeek_, what _are_ gitolite or gitosis?
[13:50] <nDuff> csgeek_, web frontends? PQMs? ...?
[13:51] <nDuff> re the former, I think Loggerhead is preferred
[13:51] <csgeek_> it allows you to limit what user can write to what using ssh RSA/DSA keys
[13:52] <nDuff> ahh
[13:52] <csgeek_> basically security mechanism for granting user rights to a repo and limit what they can and can't do
[13:52] <csgeek_> rathern then relying to unix permission.  Also prevents users from deleting "master" or whatnot
[13:52] <nDuff> see http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/security.html
[13:53] <csgeek_> thanks nDuff
[13:58] <nDuff> 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] <csgeek_> PQM = https://launchpad.net/pqm ?
[14:00] <nDuff> csgeek_, and that class of tools, yes; there are a few for git also.
[14:01] <csgeek_> I'm familiar with the git tools, it has a few shortcomings, at least work preferes bzr (:
[14:13] <jjann> 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] <jjann> bzr: ERROR: Not a branch: "/path/to/bzr/repo/svn/repo"
[14:13] <jjann> bzr st says nothing about that director though, it just shows the removes externals-snapshot
[14:13] <jjann> removed even
[14:14] <jjann> any hints on how to get out of this?
[14:19] <csgeek_> 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] <nDuff> 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] <TresEquis> especially with the "shared repository" format
[14:45] <lifeless> :)
[15:08] <mgz> garyvdm: re expensive plugins, I bet you're being screwed just by qt import times, it's a big thing
[15:08] <mgz> unless you're already very careful about lazy loading?
[15:09] <GaryvdM> mgz: we are very carefull about lazy loading.
[15:10] <GaryvdM> mgz: it's importing bzrlib.branch
[15:11] <GaryvdM> mgz: but I think the method that I used is not very accurate. :-(
[15:12] <mgz> measuring startup time isn't
[15:12] <mgz> you can do cold startup properly on nix as well, which will give you bigger numbers
[15:12] <mgz> what was the magic drop-caches command again...
[15:13] <GaryvdM> hmm - let me try that
[15:14] <mgz> echo 3>/proc/sys/vm/drop_caches
[15:14] <mgz> after a sync.
[15:29] <GaryvdM> mgz: do you know what I'm doing wrong here?
[15:29] <GaryvdM> http://pastebin.org/
[15:29] <GaryvdM> http://pastebin.org/298078
[15:36] <mgz> your shell doesn't seem to support time taking arguments
[15:37] <mgz> (time bzr rocks) 2> plugin_profile.txt
[15:37] <mgz> maybe?
[15:37]  * GaryvdM tries
[15:38] <GaryvdM> mgz - that works, but I also want to do time -f %E bzr rocks - What shell should I use?
[15:40] <mgz> bash -c "help time"
[15:40] <mgz> and see what it offers
[15:40] <mgz> otherwise... well, see what else you have installed
[15:41] <GaryvdM> hmm - thats very different to "man time"
[15:43] <GaryvdM> mgz: got it
[15:43] <GaryvdM>  /usr/bin/time -ao plugin_profile.txt -f %E bzr rocks
[15:43] <mgz> a, ha.
[15:46] <csgeek_> how do I delete a remote branch?
[15:47] <csgeek_> I suppose I can ssh and rm -fr, but is there some mechanism via bzr
[15:47] <mgz> just do the obvious.
[15:59] <jam> csgeek_: 'bzr remove-branch'
[16:00] <jam> though that was added in the 2.2 series
[16:00] <GaryvdM> mgz: just sent a mail with the cold cache results.
[16:00] <lfaraone> One of the users of GroundControl is getting http://people.ubuntu.com/~alanbell/Screenshot-Bazaar%20Error.png when attempting to push to a remote lp repository. (bug 587051) Should we handle this in GC, or is there a failure on the bzr side?
[16:02] <GaryvdM> lfaraone: The error message could be more friendly...
[16:02] <lfaraone> GaryvdM: okay, what exactly is the problem encountered, and can it be fixed programmatically?
[16:02] <GaryvdM> lfaraone: not programmatically
[16:04] <GaryvdM> lfaraone: either upgrade lp:~vcs-imports/dasher/trunk, or...
[16:04] <mgz> garyvdm: that's interesting, very different result, presumably more penalty from not lazy loading other needed modules and less from hooks in bzr core
[16:04] <mgz> wonder what the search plugin is doing
[16:05] <GaryvdM> lfaraone: recreate lp:~alanbell/dasher/bug..... as a --1.14 branch
[16:05] <GaryvdM> lfaraone: see bzr help current-formats
[16:06] <GaryvdM> lfaraone: You can convert a non-rich-root format to a rich-root format, but not the other way around :-(
[16:14] <GaryvdM> http://pastebin.org/298236 with search
[16:14] <GaryvdM> http://pastebin.org/298243 --no-plugins
[16:14] <GaryvdM> mgz: ^
[16:16] <GaryvdM> mgz: bzrlib.branch, bzrlib.xml4
[16:16] <mgz> hm, so that is mostly what john was saying in the last mailing list post.
[16:16] <GaryvdM> Could be more lazy
[16:17] <mgz> though, making the commands that don't touch branches 100ms faster still seems worthwhile
[16:17] <GaryvdM> mgz: Also I want to bring up the gui before bzrlib.branch is imported...
[16:26] <GaryvdM> Hi vila
[16:27] <vila> GaryvdM: hey !
[16:27] <GaryvdM> vila: I'm getting some test failures, an I want check if they are also happening on babune.
[16:27] <GaryvdM> vila: But I cant access babune
[16:27] <vila> where ?
[16:27] <GaryvdM> vila: karmic
[16:28] <vila> lol, I meant failures where ?
[16:28] <vila> and what do you mean by "can't access" ?
[16:28] <GaryvdM> vila: http://pastebin.org/298300
[16:28] <GaryvdM> oh
[16:28] <GaryvdM> http://babune.ladeuil.net:26862/grid
[16:29] <GaryvdM> vila^
[16:29] <vila> babune is blue and almost sunny
[16:29] <GaryvdM> oh - thats the old address
[16:30] <vila> wow, wow, wow, that's the old buildbot one, yeah ;)
[16:30] <vila> http://babune.ladeuil.net:24842/ should be better
[16:30] <vila> GaryvdM: And I thought you were running lucid ?
[16:30] <GaryvdM> vila: thaks
[16:31] <GaryvdM> vila: lucid on laptop, but not upgraded on the desktop.
[16:32] <vila> GaryvdM: beware, I started keeping various versions here and there and I ended up running babune :-P
[16:33] <GaryvdM> vila: Yhea - I'm just lazy to upgrade.
[16:33] <lfaraone> GaryvdM: okay. our goal is to avoid requiring users to have to manually do any of that. So, in the future, we should make sure that our new branches are created with the same format as the source?
[16:33] <GaryvdM> lfaraone: Yes
[16:34] <GaryvdM> lfaraone: bzr also needs a command that you can create a shared repo, in the format that you are going to branch into
[16:34] <GaryvdM> lfaraone:  we currently don't have a nice way to do that :-(
[16:36] <GaryvdM> vila: any idea why I get these failures, and how to fix: http://pastebin.org/298327
[16:38] <vila> GaryvdM: hmm, that vaguely rings a bell... is it with --no-plugins or anything fancy ?
[16:38] <vila> GaryvdM: anything weird with time or file system there ?
[16:39] <GaryvdM> vila: yes
[16:39] <GaryvdM> vila: yes --no-plugins
[16:40] <GaryvdM> vila: ext4 fs
[16:40] <GaryvdM> vila: going to try on the lucid laptop
[16:40] <vila> What can I say, using /tmp/testbzr-buzGMO.tmp is asking for trouble, tests don't like being called buggy gizmos even in disguise
[16:40] <vila> :)
[16:42] <vila> so, debugging it manually is hard, it's a blackbox one, but you could try setting a breakpoint before the failing assertion, pp self.test_dir, open a terminal there and try looking around
[16:42] <GaryvdM> vila: ok
[16:42] <vila> including running ${TEH_RIGHT_PATH}/bzr st or ${SYSTEM_WIDE_INSTALLED}/bzr st
[16:43] <GaryvdM> vila: also fails on lucid laptop
[16:43] <vila> revno ?
[16:43] <GaryvdM> 5274
[16:44] <vila> right, passed tests on babune
[16:44] <vila> 5274 on trunk right, no local changes ?
[16:44] <GaryvdM> yes
[16:45] <GaryvdM> hmm - some unknown files. let me try bzr clean-tree and run again
[16:46] <vila> GaryvdM: no !
[16:46] <GaryvdM> why?
[16:46] <vila> wait, keep them in a safe place, there is no known reason for interference from the source tree, if it is the case, we have a bug
[16:47] <vila> GaryvdM: so, put them aside and retry and but I won't hold my breath
[16:47] <GaryvdM> vila: I allready did it on the desktop, but it's also failing on the laptop, so we can debug there if needed
[16:48]  * vila reading the test
[16:48] <vila> urgh, one more eager test....
[16:50] <GaryvdM> vila: I rm the wt, did a checkout, make and it passes now
[16:50] <GaryvdM> vila: Going to debug on the laptop
[16:50] <vila> GaryvdM: anything in your setup related to .... what ?
[16:51] <GaryvdM> vila: Sorry - don't understand the question.
[16:52] <vila> I stopped writing when you said you fixed the problem by rm'ing your wt....
[16:52] <GaryvdM> ok
[16:52] <vila> You had a dirty wt ?
[16:52] <vila> on both machines ?
[16:52] <GaryvdM> yes
[16:53] <vila> tell us your dirty secrets will you...
[16:53] <vila> what did *you* do to that poor wt ?
[16:53] <vila> unresolved conflicts ?
[16:54] <GaryvdM> Not sure
[16:56] <GaryvdM> The plot thickens
[16:56] <GaryvdM> The wt was not related.
[16:57] <GaryvdM> If I run ./bzr selftest --no-plugins branch - I get the failures
[16:57] <GaryvdM> If I run ./bzr selftest --no-plugins -s bzrlib.tests.blackbox.test_status.CheckoutStatus.test_branch_status - it passes
[16:57] <GaryvdM> vila^
[16:57]  * vila trying
[16:58] <vila> with -s the plugins are loaded
[16:58] <vila> err, sry, you have --no-plugins there too
[16:58] <vila> eeeerk
[16:59] <vila> vada retro satanas failing here, I wasn't there I hear nothing, I saw nothing
[17:00] <vila> so, this smells test isolation
[17:00] <vila> maybe a hook was added recently in this area and was not registered in b.h.known_hooks ?
[17:00] <GaryvdM> vila: There was a BZR_PDB for tests, but I can't find it now.
[17:02] <GaryvdM> vila: Maybe it was in my imagination ...
[17:02] <vila> hmm, no I think there is one
[17:03] <vila> BZR_TEST_PDB
[17:03] <GaryvdM> vila: Thanks. btw where did you find that?
[17:04] <vila> emacs...
[17:04] <vila> :-P
[17:04] <vila> I searched for PDB in bzrlib/tests/__init__.py
[17:04] <GaryvdM> ok
[17:05] <vila> GaryvdM: can you run qblame bzrlib/status.py and tell me if th revnos are truncated for you too
[17:07] <GaryvdM> vila: Yes
[17:08] <GaryvdM> vila: we try guess how much space we need, by just looking at the tip revno. We should look at the length of each revno that is shown
[17:09] <mgz> but see bug 504070
[17:09] <GaryvdM> vila: taking into account font metrics, I'm worried that it will be slow.
[17:09] <vila> GaryvdM: just give me a way to resize interactively :)
[17:10] <GaryvdM> vila: yes
[17:14] <vila> GaryvdM: do you often run ~3000 tests in a single selftest ?
[17:15] <vila> GaryvdM: did your failing runs ended mentioning a high number of leaking tests ?
[17:15] <GaryvdM> vila: no - I want to make some imports lazy in bzrlib.branch - so I want to test lots of things
[17:16] <vila> the no was for the ~3000 ?
[17:16] <GaryvdM> Yes
[17:16] <GaryvdM> vila: 17 non-main threads were left active in the end.
[17:16] <vila> how many leaking tests ?
[17:17] <GaryvdM> bzrlib.tests.blackbox.test_branch.TestBranchStacked.test_branch_stacked_from_smart_server is leaking threads among 13 leaking tests.
[17:17] <vila> next line
[17:17] <vila> err, what 13 only, lier :)
[17:17] <GaryvdM> vila: bzr: interrupted - I'll run it again
[17:18] <j0rd> I'm about to switch my whole VCS over to git, sell me on bzr. I'm interested in installing and using launchpad and just read about the usability of bzr. got me thinking
[17:18] <vila> haaa, I got 591 leaking tests and 166 non-main thread left active
[17:18] <mgz> hey, that's better than 1600
[17:18] <vila> on top of that, there are may sockets left open, so you may be experiencing a 'Too Many Files Open' exception that is silently swallowed
[17:19] <vila> mgz: that's for trunk :)
[17:19] <GaryvdM> j0rd: Here is a page with good reasons: http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html
[17:19] <j0rd> GaryvdM: reading it now
[17:19] <j0rd> GaryvdM: i was interested in real users expereiences as well
[17:19] <vila> once I finished implementing all my pending tricks, I should be close to 0 unexplained thread leaks
[17:20] <j0rd> i use ubuntu as well, which is another selling point of bzr, but other than that....i've never really heard of people using it
[17:20] <mgz> if you can get the working set of a full test run back down to 200MB rather than 1GB I'll be very happy
[17:20] <vila> mgz: and by cheating a bit I know that instead of >1024 sockets for a full run, I'm now at ~50 (some of which being "valid")
[17:21] <vila> mgz: no idea about that yet, first things first :)
[17:21]  * vila back to hacking
[17:21] <kostja_osipov> j0rd: we use bazaar quite extensively here at MySQL, moved from BitKeeper.
[17:22] <kostja_osipov> I'd say it's a pretty good tool, although we do have internal advocates with git
[17:22] <kostja_osipov> the main selling point for me with bzr would be that you can get paid support from the vendor for it.
[17:22] <j0rd> kostja_osipov: i assume you have used the others as well "cvs, svn, git?" which is the stream i'm coming from.
[17:23] <kostja_osipov> svn was out of the question when we migrated, being a "better cvs"
[17:23] <kostja_osipov> git was high on the list, mainly because of its speed.
[17:23] <j0rd> kostja_osipov: alright, not looking for paid support, but i do like the web frontend launchpad...which currently is my major selling point. I need something web frontend, that i can show to my clients and have them interact with for bugs and documentation
[17:23] <kostja_osipov> but git wasn't as mature as it is now when we migrated, back in 2008
[17:23] <vila> GaryvdM: one more thing: 'branch' get you 3000 tests, most of them involving servers, with leaks, so you're doing the opposite of the --parallel=fork trick: instead of spreading the leaks, you're attracting them :-D
[17:24] <kostja_osipov> j0rd: well, that's launchpad platform, it's way more than just bzr
 but git wasn't as mature as it is now when we migrated, back in 2008 <- it was, it was just less of a meme than it is now
[17:24] <j0rd> kostja_osipov: i'm aware of that, it's something I'll need
[17:24] <kostja_osipov> we use our own development infrastructure (e.g. bugs.mysql.com, with bzr triggers in python that keep the bug database in sync with the trunk state), and only partially integrate to launchpad
[17:24] <GaryvdM> vila: ack
[17:24] <kostja_osipov> mgz: we needed Windows support.
[17:25] <mgz> which git still doesn't have.
[17:25] <mgz> running half a unix system underneath it doesn't count.
[17:25] <kostja_osipov> mgz: when you choose a tool for a large open source project, you want all platform to be well supported.
[17:25] <kostja_osipov> and bzr was better than others in that.
[17:25] <mgz> bazaar has improved much more in the last two years than the other vcses
[17:25] <kostja_osipov> mgz: well, I think it's better now than before. I haven't been looking
[17:26] <j0rd> ease of use is important for me, because i'm a free lancer and if the people I work with can't figure out my VCS, it'll cause problems
[17:26] <j0rd> another reason I'm looking towards bzr right now
[17:26] <mgz> you can get a pre-packaged msys with your git now, it is still a sucky option
[17:26] <GaryvdM> vila: that test says it is a blackbox test. I thought that ment a subprocess, but that is not the case. Is my understanding of what blackbox implies wrong?
[17:26] <kostja_osipov> mgz: Haven't been watching closely. I can say bzr still has a way to go to be my real BitKeeper replacement. But I can't say it doesn't get the job done.
[17:26] <kostja_osipov> and in some parts it's of course better than bk
[17:27] <mgz> yup, there's a long way to go all round.
[17:27] <kostja_osipov> j0rd: how big is your project?
[17:27] <vila> GaryvdM: yes, a blackbox test runs with stdout/stderr/stdin redirected, subprocess is not a requirement and we try to avoid them
[17:27] <kostja_osipov> how many people work on it?
[17:28] <j0rd> kostja_osipov: many small projects, for one off clients
[17:28] <vila> GaryvdM: stdout/stdin being redirected, pdb can't be used
[17:28] <j0rd> kostja_osipov: about 1-3 months in lenght each
[17:28] <j0rd> kostja_osipov: drupal development. Ubercart uses bzr as well
[17:28] <j0rd> and i do mostly ubercart work
[17:28] <j0rd> so another selling point
[17:29] <kostja_osipov> I'd say if you're under 500 000 and 5 years of active history, you won't notice much of bzr drawbacks.
[17:30] <kostja_osipov> at least they are not apparent to me on that scale.
[17:30] <j0rd> kostja_osipov: i'm really just looking for a frontend to my VCS, so that i can update my clients on progress upon commit and self document along the way. allowing them to see progress, track bugs and i can document features as they get built
[17:30] <kostja_osipov> my issue was with performance and with bzr file-ids...
[17:30] <kostja_osipov> and some gui quirks... I'd like the gui to be more flexible.
[17:30] <kostja_osipov> but otherwise... does the job.
[17:31] <j0rd> kostja_osipov: ya, i'm fairly VCS agnostic to be honest. so the front end interface for my clients is actually more important to me. and having other colaborators pick it up easily
[17:31] <GaryvdM> kostja_osipov: Which gui: gtk, or qbzr?
[17:31] <kostja_osipov> (and you only start to be getting performance issues when  you're in millions of slocs)
[17:32] <kostja_osipov> I use gtk but I miss some very specific interface that was good in BK
[17:32] <kostja_osipov> gotta go (dinner)
[17:33] <j0rd> kostja_osipov: thanks for your insight, very helpful
[17:33] <GaryvdM> j0rd: It is very easy to run your own loggerhead. (http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk2a/files is loggerhead)
[17:33] <vila> kostja_osipov: tell us at least what you're missing, we're holding our breath !
[17:33] <vila> kostja_osipov: :)
[17:34] <GaryvdM> kostja_osipov: If you don't mind qt to much, give qbzr a try.
[17:34]  * GaryvdM plugs away shamelessly
[17:35] <kostja_osipov> I will. I'm missing bk sccstool to be precise
[17:36] <kostja_osipov> where you start with the revision history tree view, and can scroll back and forth in time and instantly get to every changeset.
[17:36] <kostja_osipov> really need to go
[17:37] <GaryvdM> kostja_osipov: sounds like bzr qlog
[17:39] <jjann> I have a branch with a broken attempt of trying bzr-externals, everytime I try to commit on this branch, I just get an "bzr: ERROR: Not a branch: /path/to/the/old/external/thingy", any hints on how to get past this? I tried using uncommit to get to a stage before this happened but no luck
[17:53] <jjann> ok, deleting .bzrmeta/externals completely helped
[18:32] <GaryvdM> vila: test results: http://pastebin.org/298796
[18:33] <GaryvdM> vila: The problem is caused by trace.is_quite() returning True. I'm going to log a bug.
[18:36] <GaryvdM> Ah - Allready loged. 579996
[18:36] <GaryvdM> bug 579996
[18:45] <Abhijeet> hi all
[18:45] <Abhijeet> our company currently using jazz clearcase server from IBM
[18:45] <Abhijeet> we are thinking to replacing this with new SVC..
[18:46] <Abhijeet> Our servers are based on HPUX os.
[18:46] <Abhijeet> so is BZR well supported on it?
[18:49] <maxb> HPUX is pretty rare. Your chances of finding someone who knows about it on IRC are fairly slim
[18:49] <maxb> But if it can run Python and a decent C compiler, chances are good
[18:59] <Abhijeet> hpux has it's own compilers.
[19:58] <exarkun> bzr locks seem to last across reboots on Windows
[19:58] <exarkun> That's a bit unfortunate, eh?
[20:02] <GaryvdM> exarkun: you just need to break the lock with bzr break-lock
[20:02] <exarkun> GaryvdM: I know.  But I don't see why I should need to.
[20:03] <bialix> heya
[20:03] <GaryvdM> Hi bialix
[20:04] <bialix> I have question about pqm setup
[20:04] <bialix> actually 2 questions
[20:04] <bialix> 1) Does example in the HACKING.txt is still correct? it talking about sftp and b-v.o URLs so it seems pretty outdated
[20:05] <bialix> 2) Why it so overly-complicated? Is there wrapper around pqm plugin suitable for lazy and dumb windows devs who need only submit requests to bzr pqm?
[20:06] <bialix> hi Garyvdm
[20:07] <GaryvdM> bialix: yes HACKING.txt does seam out of date. From my locations.conf: http://pastebin.org/299166
[20:09] <GaryvdM> bialix: re question 2 - It does not only apply to windows...
[20:14] <GaryvdM> exarkun: Probably not the most knowable person to answer that question. I believe it is because the locks are handled by bzr, and not the os, and bzr does not know when the machine is restarted.
[20:15] <GaryvdM> exarkun: The reason why bzr handles the locks, is it needs to be able to write to transports like ftp, where we can't do os locks.
[20:16] <exarkun> GaryvdM: That's probably true.  bzr should use a lock that gets reset across reboots, instead of whatever it uses now.
[20:17] <exarkun> I filed a bug report, https://bugs.launchpad.net/bzr/+bug/588431
[20:17] <GaryvdM> ok
[20:26] <bialix> exarkun: I don't think so
[20:27] <bialix> GaryvdM: oh, nice, thanks for the example
[20:27] <exarkun> bialix: The purpose of the lock is to prevent concurrent access.  If the lock was held by a process that existed before the last reboot, then there is no chance of concurrency.
[20:27] <bialix> exarkun: the problem with limbo is a known bug
[20:28] <bialix> exarkun: everything else is require more intelligence than bzr has right now
[20:28] <bialix> it's not so hard to run break-lock, is it?
[20:28] <exarkun> Yes, it is.
[20:29] <bialix> GaryvdM: cool, I was not sure I can use lp: style urls
[20:29] <exarkun> If I were actually the agent running "bzr checkout", then maybe it wouldn't be so hard to manually break the lock.
[20:29] <exarkun> But I'm not.  An automated build system is.
[20:30] <bialix> yep
[20:31] <GaryvdM> bialix: yes, except for the submit branch.
[20:31] <exarkun> So far I'm finding bzr to be somewhat lacking in reliability.  I could easily use svn in an automated build system.  It was slow, but it just about always worked.  bzr, on the other hand, is much faster for many operations, but fails in a lot of different ways.
[20:31] <exarkun> So, I hope #588431 (and the other bugs I've filed) are considered real issues and eventually addressed.  I'd much rather be able to continue using bzr in the future, rather than having to switch back to svn.
[20:32] <bialix> yes
[20:48] <bialix> Garyvdm: I want a pony^W qpqm-submit command. And planning to do so tomorrow
[20:49] <GaryvdM> bialix: :-)
[20:49] <GaryvdM> bialix: I want to look at our start up time on windows
[20:50] <bialix> btw, I've started dogfooding bzr-explorer every day
[20:50] <bialix> it needs to be improved
[20:50] <bialix> one things that bother me: we need to invent a way to add "edit file" command to treewidget context menu
[20:51] <bialix> GaryvdM: cool
[20:52] <GaryvdM> I did a clean install of windows, and the start time is not bad. But I have seen on windows installs that have been around for a while, the start up is very slow.
[20:52] <GaryvdM> bialix: like you laptop.
[20:52] <GaryvdM> *your
[20:52] <bialix> hmm
[20:52] <GaryvdM> Open = edit file
[20:54] <bialix> no
[20:54] <bialix> open is launched file
[20:54] <GaryvdM> bialix: I would like to try make an installer without libaray.zip, to see if it makes a difference, but the instructions to build the installer made me very scared...
[20:54] <bialix> so open for python file is just launched its execution
[20:55] <bialix> GaryvdM: really? I'm ever don't know if there is up-to-date instructions
[20:55] <bialix> why you need installer?
[20:56] <GaryvdM> bialix: I think that maybe if we don't have libaray.zip, the start up will be faster, I would like to prove/disprove this.
[20:56] <bialix> you don't need installer for this
[20:57] <bialix> you can build bzr.exe with `python setup.py py2exe` command
[20:57] <bialix> and there is one place n setup.py where you can control creation of library.zip
[20:57] <GaryvdM> bialix: re Edit File - maybe show the options for the different edit applications registerd in windows, like windows explorer?
[20:58] <GaryvdM> oh - ok
[20:58] <bialix> GaryvdM: if you run bzr-explorer -- then you can see edit action (icon of paper with pen) which opens selected file in treewidget in the editor
[20:59] <bialix> we need a way to mirror this action in treewidget
[20:59] <bialix> allow explorer to inject this action
[20:59] <bialix> IIRC there is bug report on this
[21:00] <bialix> GaryvdM: which instructions scare you?
[21:02] <GaryvdM> bialix: bzr.dev/doc/developers/win32_build_setup.txt
[21:02] <GaryvdM> Thats just to install the dependencies.
[21:03] <jam> GaryvdM: what is your alternative to library.zip ? A loose tree of files?
[21:03] <GaryvdM> Then you have to get all the plugins
[21:03] <jam> i'm pretty sure that would be slower
[21:03] <GaryvdM> jam: yes
[21:03] <jam> .zip already has an index at the back
[21:03] <jam> and the actual content is stored uncompressed
[21:03] <jam> And navigating the python import path is a real pain on Windows
[21:04] <jam> (and so is trying to measure cold-start performance)
[21:05] <jam> GaryvdM: I thought bialix had done some testing to show that the pre-built installer was quite a bit faster than running from source
[21:05] <jam> but it has been a while
[21:05] <GaryvdM> jam: apparently you can do   options = {"py2exe": {"skip_archive":1}}
[21:05] <GaryvdM>  
[21:05] <bialix> jam: it was faster for me, at least on FAT32
[21:05] <bialix> but I can't say for sure about NTFS
[21:06] <bialix> hi jam, btw
[21:07] <GaryvdM> I think that a py2exe exe probably does not scan the installed python paths, which would explain why it's faster.
[21:07] <bialix> Garyvdm: those could be simpler a bit: http://wiki.bazaar.canonical.com/BzrWin32Installer
[21:07] <bialix> GaryvdM: actually py2exed application has only library.zipin sys.path
[21:08] <bialix> GaryvdM: actually py2exed application has only library.zip in sys.path
[21:08] <GaryvdM> bialix: Yes, thats what I was trying to say
[21:08] <GaryvdM> bialix: thanks for the better doc.
[21:09] <bialix> GaryvdM: they're out-of-date a bit
[21:09] <bialix> feel free to blame
[21:09] <GaryvdM> jam, bialix: we don't need MS Visual Studio for tbzr any more?
[21:10] <bialix> no, we need
[21:10] <bialix> maybe you can skip tbzr?
[21:11]  * bialix is about to going offline
[21:12] <GaryvdM> I thought that req was removed. :-(
[21:12] <bialix> how fullermd said? rest is for wimps? so I am
[21:12] <bialix> ~~~
[21:14] <jam> GaryvdM: You need at least the 'light' version, but I've never actually worked out how to do it
[21:14] <jam> naoki was good enough to figure out how to use express edition + an sdk
[21:14] <jam> but as bialix mentioned, that is mostly just for the tbzr extension
[21:15] <jam> I thought you had access to Desolation, though (the win32 build host)
[21:15] <GaryvdM> jam: No :-(
[21:27] <aarfeick_> I have a question on bug tracking... is anyone here knowledgable about it?
[21:29] <mkanat> aarfeick_: Bug tracking in general, or bug-tracking with launchpad?
[21:30] <aarfeick_> Well, I wrote my own bug tracker (as an exercise)
[21:30] <aarfeick_> I developed a URL scheme to close bugs
[21:30] <aarfeick_> My commits indicate the URL of the fix, but I don't think Bazaar is actually resolving that URL
[21:31] <aarfeick_> Any ideas why?
[21:31] <jelmer> aarfeick_: What do you mean with your commits indicate the URL of the fix?
[21:32] <mkanat> aarfeick_: The bzr bugtracking support doesn't do anything to the bug-tracker.
[21:32] <mkanat> aarfeick_: It just stores a URL to the bug-tracker in bzr.
[21:32] <aarfeick_> When I use bzr commit -m "Test commit" --fixes my_tracker:123, the commit logs show the URL that I specified in my config
[21:32] <aarfeick_> I see
[21:32] <aarfeick_> I thought the point was to actually apply the fix using that URL
[21:33] <jelmer> aarfeick_: no, it just tracks that a particular bug was fixed by a particular revision
[21:33] <aarfeick_> I see...
[21:33] <aarfeick_> I suppose I'd have to write a hook to do anything about it?
[21:33] <mkanat> aarfeick_: Yeah.
[21:34] <jelmer> aarfeick_: in launchpad's case it scans branches that are pushed for this revision proprety
[21:35] <aarfeick_> Is there a (relatively) simple way to do so, that I could distribute to the rest of my development team? I fear I know nothing about bzr hooks.
[21:35] <mkanat> aarfeick_: You could have the bug-tracker scan the VCS.
[21:36] <aarfeick_> Oh... so it could scan the logs for the fix statement
[21:36] <aarfeick_> My current implementation of the tracker is web-based so it can be used by other developers
[21:36] <aarfeick_> So it would not be so simple
[21:36] <lifeless> moin
[21:46] <aarfeick_> In this case, I'd want to write a hook that "visits" a certain URL, which the bug-tracker uses to actually close the bug
[21:46] <aarfeick_> Is there a *good* way to do this in Python?
[21:47] <exarkun> By "visits" do you mean "issues an HTTP GET to"?
[21:48] <lifeless> aarfeick_: a post commit hook could do "bzrlib.transport.get_transport(bugfix_url).get('.')" or you could use httplib/httplib2/twisted's getPage etc etc
[21:49] <aarfeick_> exarkun: yes, an HTTP GET.
[21:49] <exarkun> Yea, what lifeless said.
[21:49] <exarkun> There's like a million Python libraries for that. :)
[21:50] <aarfeick_> Excellent! I'm just learning Python (though I do know several other languages), and I figured this is a good useful project.
[21:50] <aarfeick_> The tracker is in PHP
[21:52] <GaryvdM> jam: Is there a reason bzrlib.errors one big file? It is quite costly to import.
[21:53] <GaryvdM> dito for bzrlib.builtins
[21:55] <GaryvdM> I'm trying to delay the importing of bzrlib.errors. It's a wack a mole game....
[22:02] <lifeless> GaryvdM: they are
[22:03] <lifeless> GaryvdM: I've considered a few things, like putting them one-per-error in separate py files
[22:03] <lifeless> more realistic to do that for builtins to start with, I think.
[22:06] <GaryvdM> lifeless: ok
[22:12] <lifeless> GaryvdM: however
[22:12] <lifeless> GaryvdM: for builtins.py we have to load it for most commands
[22:12] <lifeless> GaryvdM: for errors, if we catch *any* exception, we have to load it.
[22:13] <lifeless> So lazy loading is a misleading tool for performance improvements here.
[22:13] <lifeless> The key thing is, how much code do we load *doing a users operation*
[22:13] <lifeless> and how much code do we *use* to do that operation
[22:14] <GaryvdM> lifeless: My objective is to get those things to only import after I have got a qbzr window up
[22:15] <GaryvdM> lifeless: I know it's just delaying the inevitable...
[22:16] <GaryvdM> lifeless: I've made some progress. I can now import bzrlib.branch with out importing bzrlib.repofmt.pack_repo :-)
[22:17] <TresEquis> ugh, just had bzr revert --forget-merge still leave my sandbox hosed (due to conflicts)
[22:17] <TresEquis> I would expect all the conflicts to get washed away by the revert
[22:17] <lifeless> the difference is stuff we can work on
[22:18] <lifeless> GaryvdM: how do users invoke qbzr ?
[22:18] <GaryvdM> lifeless: Either the command line, or tbzr, or bzr explorer
[22:18] <lifeless> details!
[22:18] <lifeless> gimme gimme details
[22:19] <GaryvdM> bzr qlog
[22:19] <lifeless> ok
[22:19] <lifeless> so
[22:19] <lifeless> how do you feel about 'qbzr log'
[22:20] <GaryvdM> lifeless: hmm - I don't know
[22:21] <GaryvdM> lifeless: I'll think about that.
[22:21] <lifeless> that would make it trivial to avoid builtins.py - you wouldn't want all the bzr commands loaded *anyway*
[22:21] <lifeless> and similarly errors.py would only need commands.py and options.py to be audited
[22:22] <lifeless> a small tweak to the command lookup invocation code in your frontend would make 'qbzr log' load 'qlog' as the command object
[22:22] <lifeless> and you can register the stock bzr command providers after you're in your mainloop
[22:23] <lifeless> [if you want them at all, that is]
[22:23] <lifeless> if you're not calling into cmd_foo objects, then you don't need to register them *at all*
[22:23] <GaryvdM> lifeless: I don't think builtins is a problem  - I'll check
[22:24] <GaryvdM> lifeless: The other way to solve the problem is a central hook registry as per mailing list discussion.
[22:25] <lifeless> that won't solve the problem
[22:25] <lifeless> builtins.py, which you mentioned at :53 is *already* demand loaded by hooks
[22:26] <lifeless> you'll get precisely 0.0 time saves from hook infrastructure changes for builtins.py
[22:27] <IslandUsurper> TresEquis, I think bzr detects text conflicts from the markers in the files. revert --forget-merge doesn't touch the working tree, so the conflicts would remain
[22:27] <lifeless> TresEquis: 'bzr revert' - resets files and merge info
[22:27] <lifeless> TresEquis: 'bzr revert .' - rests just files
[22:28] <lifeless> TresEquis: 'bzr revert --forget-merges' - resets just merge info
[22:28] <GaryvdM> lifeless: ok - sorry the builtins comment was just an observation. The bigger problem is plugins importing bzrlib.branch to register hook.
[22:28] <lifeless> GaryvdM: thats not a problem for the command line
[22:29] <GaryvdM> lifeless: yes
[22:29] <lifeless> GaryvdM: And there is a lot of stuff in branch.py we should move into a format package
[22:29] <lifeless> like we did for repository
[22:29] <lifeless> that would make branch.py cheaper
[22:30] <lifeless> not saying that the hook changes might help
[22:30] <lifeless> but for branch.py it only defers stuff
[22:30] <lifeless> better to avoid it completely; and we have 4 formats or so, only need the code for one.
[22:30] <GaryvdM> lifeless: Yes, thats what I've been trying to do (make import bzrlib.branch cheaper) (maybe with the wrong approach)
[22:31] <TresEquis> lifeless:  thanks, that helps
[22:33] <lifeless> GaryvdM: I'd like to see the following made cheaper "using a branch"
[22:33] <lifeless> GaryvdM: think whole-operation costs, not import costs.
[22:33] <lifeless> that would benefit *everything*
[22:33] <GaryvdM> lifeless: ack
[22:34]  * lifeless hands the furball back
[22:34] <GaryvdM> http://bazaar.launchpad.net/~garyvdm/bzr/delay_imports/revision/5276
[22:36] <GaryvdM> lifeless: ^ that makes import bzrlib.branch not import  bzrlib.repofmt.pack_repo
[22:38] <GaryvdM> jon$yd
[22:39] <GaryvdM> darn - wrong window
[22:39] <lifeless> lol
[22:41] <GaryvdM> time to change lots of passwords...
[22:46] <exarkun> GaryvdM: To different things, this time.
[22:46] <GaryvdM> exarkun: My brain wont cope with that
[22:46] <exarkun> GaryvdM: That's okay.  Use technology.
[22:47] <GaryvdM> exarkun: Important things like bank are different
[23:13] <aarfeick_> How precisely would I use the iter_bugs function in revision.py?
[23:13] <aarfeick_> I'd like access to the bug URL's for a revision in a post-commit hook.
[23:22] <aarfeick> I am having trouble using iter_bugs() in revision.py...
[23:23] <lifeless> yes?
[23:24] <GaryvdM> lifeless: I just tested, and what I've done makes bzr status import less. (I'm not sure what exactly yet. It quite hard to compare 2 profile-imports)
[23:25] <lifeless> GaryvdM: I'm not really all that interested in profile-imports
[23:25] <lifeless> GaryvdM: I'm interested in 'time bzr st'
[23:26] <GaryvdM> ok
[23:26] <lifeless> with (say) a 20K file tree
[23:26] <lifeless> or 100K if your machine is too fast to detect changes on 20K
[23:26] <lifeless> GaryvdM: profile imports and similar are tools to direct performance effort, but they are poor proxies for actual time-spent.
[23:27] <lifeless> GaryvdM: remember that importing all of bzr and plugins etc on modern machines is < 0.5 seconds
[23:28] <lifeless> GaryvdM: oh also, if working on just getting-started speed, also time bzr st on very small trees
[23:28] <lifeless> you'll have some chance of making the import time dominate
[23:28] <GaryvdM> lifeless: yes - I've been timing bzr st on small trees, but not large trees
[23:29] <lifeless> the risk with large trees will be near-zero if you're not changing code in loops
[23:29] <lifeless> but I don't know what you're doing, so I mention it to make sure you're aware of the space we've optimised status within
[23:29] <GaryvdM> lifeless: I'm also testing with cold cache, and warm cache
[23:30] <lifeless> yes
[23:35] <lifeless> jelmer: have you seen hydrazine?
[23:36] <jelmer> lifeless: yes
[23:36] <lifeless> I'd love it if you use it
[23:36] <lifeless> because we could start generalising and pulling its features up into lp proper
[23:37] <lifeless> you don't have to
[23:37] <lifeless> just saying
[23:38] <jelmer> lifeless: I do use it, I contributed some trivial fixes IIRC :-)
[23:39] <lifeless> jelmer: ah! perhaps you have a stale branch :)
[23:39] <jelmer> lifeless: which features are you thinking of though?
[23:39] <jelmer> I've mostly used bugclient so far
[23:39] <lifeless> feed-pqm
[23:41] <poolie> hi jam
[23:41] <poolie> hi lifeless, GaryvdM, jelmer
[23:41] <lifeless> hey
[23:42] <GaryvdM> Hi poolie
[23:54] <GaryvdM> How come doing a status on a 2a branch imports xml code. I thought that 2a used bencode rather than xml.
[23:55]  * GaryvdM sees if making that lazy makes a difference.
[23:58] <lifeless> GaryvdM: better to not load it, than to make it lazy
[23:58] <lifeless> GaryvdM: lazy loading has given us some really nasty structures