/srv/irclogs.ubuntu.com/2010/06/01/#bzr.txt

igcmorning00:38
lifelesshiya00:38
codebrainzhi.  is there something out there that "plugs in" to something like loggerhead to administer repos/branches/users and whatnot?01:02
lifelesscodebrainz: not that I know of01:05
lifelessit might be nice though! perhaps you could file a bug on loggerhead asking for that01:05
lifelesspoolie: got a minute for a chat ?01:05
codebrainzis loggerhead in python?01:05
lifelessyes01:05
lifelesslaunchpad.net/loggerhead01:05
codebrainzmaybe I'll work on a patch01:06
lifelessthat would be awesome01:06
pooliehi there lifeless01:06
pooliesure01:06
mwhudsoni think there is already a bug asking for more 'write access' type stuff in loggerhead01:14
steven_thello01:14
steven_thave any of you previously used git or hg?01:15
mlhI'm pretty sure everyone here would have tried both01:23
steven_twhysat?01:24
mlhsteven_t: do you have a deeper question trying to get out?01:25
steven_tno.01:25
steven_tive 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_tso far git is the winner, because its so modularized and widely supported01:26
mlhI think they're all very good, myself01:26
mlhbzr and hg are supposed to be easier to learn, bzr in particular tries to be user friendly01:26
maxbmodularized?!01:27
mlhsteven_t: have you used other vcs's before, like rcs or cvs or svn?01:27
steven_tnone.01:28
mlhthe choice in part also depends on whether you're going to be casual or heavy user01:28
mlhare you familiar with diff and patch?01:28
steven_tno01:29
steven_ti want to become a heavy user, im a coder and plan to be a professional01:29
mlhwhat sort of coding and how long have you been coding?01:30
steven_twell technically im already a professional, but what im learning in my spare time is more unixy than my dayjob (cocoa)01:30
steven_tto answer your question: http://blog.degutis.org/post/651422590/i-think-im-a-little-crazy01:30
maxbgit is excessively complex, and rather arcane, IMO. I'd favour bzr or hg, especially if you're without previous VCS knowledge01:30
mlhwhat maxb said.01:31
mlhalthough without the 'excessively'01:31
mlhnice read; either bzr or hg would be fine for you01:33
mlhI'd also consider a code completing editor, although good fast typing skill is always valuable :-)01:33
mlhdjango use svn, so you might want to try that first; sometimes the best thing to try is what the people who you work with use01:35
mlhdo you just use one machine mostly?01:35
lifelesspoolie: thanks :)01:41
igclifeless: 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:39
lifelessigc: yes, it builds the docs - we check they build on every commit, just like code02:41
lifeless[which is another reason I want all the docs in the one tree, but thats a different discussion]02:41
lifelessigc: 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:42
igclifeless: we need python-sphinx02:43
lifelessis that the entirety ?02:43
igclifeless: 0.6 or later02:43
igclifeless: I believe so02:43
lifelesshah02:43
lifelessso we're still on hardy02:43
lifelessit has < 0.5.202:43
lifelesssorry, <= 0.5.202:43
igclifeless: building the PDFs are messier though - LaTeX toolchain02:43
igclifeless: it *may* work there (in terms of building something)02:44
lifelessI'm loathe to disable checking the docs on commit02:44
igci.e. 0.5.2 may be ok02:44
lifelesswe've caught doc syntax errors that way02:44
lifelessI'll file an rt02:45
lifelessand we can see what happens.02:45
igclifeless: I agree - let's keep the doc build step as a check02:45
igclifeless, poolie: was there a consensus on https://code.edge.launchpad.net/~ian-clatworthy/bzr/cmds-in-userref-585667/+merge/26004 ?02:46
poolieigc if it doesn't break the import tests it's ok with me02:47
lifelessigc: I'd be happiest with just calling the register method from the doc generators02:47
lifelessigc: because they are essentially mini front ends, its appropriate that they do that02:47
lifelessigc: this isn't in conflict with poolies comments02:48
igcpoolie: test_import_tariff passes with my fix fwiw02:50
pooliethen it's ok with me02:50
lifelessits not with me02:50
poolieif someone later wants to tighten it up while keeping both your test and the import tariffs passing they can02:51
lifelessit will undo work done for commandant02:51
igclifeless: how?02:51
igclifeless: it only uses the builtins if none are already registered afaict02:52
lifelessigc: right, so if none are registered you'll show the bzr specific ones02:52
igclifeless: yes02:52
lifelesswhich is wrong02:52
lifelessif none are registered, none are registered02:52
lifelessI 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
lifelessbut I really do think its worth having a clear separation02:53
pooliemm, this code is not super generic at the moment anyhow02:54
lifelesspoolie: its used as a generic core by commandant, by lptools, and possibly others02:55
spivI thought commandant reimplemented it?02:56
lifelessas jkakar wanted more facilities he decided to layer on us02:56
lifelessI reworked things to make that possible02:56
spivAh ok.02:56
lifelesshe has a patch to further reduce stuff in commandant, but that got push back02:57
lifelessand it outside of the commands.py core anyhow, it was about reuseing the cmd_help object and the like02:57
lifelesss/it/is/02:57
lifelessigc: 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:58
lifelessigc: 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
poolielifeless, i'm pretty sure i made the change that ian's correcting here, not jamu02:59
lifelesspoolie: I'm pretty sure I made it02:59
poolieah02:59
igclifeless: we don't know how many clients are broken by the change02:59
lifelesspoolie: but lets look deeper02:59
lifelessok03:00
igclifeless: at least the doc generators are broken - they are easily fixed03:00
lifelesspoolie: I think you're right, the doc generators already call install_bzr_command_hooks03:00
lifelessok, land it.03:01
lifelessmy complaint is rescinded03:01
lifelesssorry for the noise03:01
igclifeless: I'm not sure the doc generators call install_bzr_command_hooks btw03:02
lifelessigc: see generate_docs.py03:02
lifelessigc: that is the front end, isn't it ?03:02
igclifeless: yep - it is03:02
lifelessigc: it appears to call it03:03
lifelessigc: please do correct me if I'm wrong03:03
igclifeless: you're correct - my mistake03:03
igclifeless: i was looking in the layer below last week (bzrlib/doc_generate)03:05
lifelessso install_bzr_command_hooks is the thing that should be called to make bzr commands visible03:05
lifelessit installes _get_bzr_command03:05
lifelessand _list_bzr_commands03:05
lifelessand if its not enough, then there is a bug03:06
lifelesswhich is why I've retracted my objection: I was misremembering the function name I needed to care in detail about03:06
lifeless\o/ 247 emails unread, down from 1400 this morning (UDS and moving backlog finally getting under control)03:08
* igc lunch - bbl03:08
lifelessEODing - started at 603:53
bialixhi06:01
bialixigc: still here?06:01
igchi bialix!06:02
bialixhi igc!06:02
bialixI have a question about bzr-exlorer project06:02
bialixthere is separate documentation for it06:02
bialixwhere is the branch?06:02
igcbialix: lp:bzr-explorer-website06:02
bialixigc: I think it's worth to change ownership of this project to bzr-explorer-dev or something similar. what do you think?06:03
igcbialix: +106:04
* igc looks06:04
bialixwho is in charge to upload these docs to bazaar site?06:04
bialixigc: ^06:05
igcbialix: it's done automatically by a cron job ...06:05
bialix?06:05
bialixdirectly from your branch?06:06
igcjust make the changes to bzr-explorer-website and it will appear within an hour typically06:06
igcfrom trunk, yes06:06
bialixso so, branch ownership should be changed to explorer-devs too06:08
bialixigc: anything other I should be aware of?06:09
igcbialix: maybe the bzr-docs team ought to be the maintainer of bzr-explorer-website?06:09
bialixmaybe, I dunno06:09
bialixigc: there is no bzr-docs team on lp06:10
bialix~bzr-doc is06:10
bialixI'm ok with ~bzr-doc as owner06:11
bialixigc: when your vacation starts?06:12
igcbialix: I'm around this week and next06:13
igcbialix: till the 9/Jun at least06:13
bialixok06:14
* bialix has no more questions so far06:15
bialixthanks igc!06:15
igcbialix: fyi, most of the other bzr doc projects are maintained by Bazaar Developers (~bzr)06:17
igcbialix: that's a restricted team06:17
igcwhich I'm thinking the owner of bzr-explorer-website ought to be06:17
igcotherwise, anyone can "join-up" and spam the site06:17
igcbialix: ^^^06:18
igcbialix: is switching ownership to ~bzr ok by you?06:19
igc(i.e. ownership of bzr-explorer-website)06:19
bialixmmm, yes06:20
bialixbut *I* am not memebr of ~bzr06:20
bialixneed to join (again)06:20
igcbialix: yes, I just noticed that06:20
bialixI will do06:20
igcbialix: cool (and thanks)06:21
bialix:-)06:23
fullermdShucks, after all that time keeping ~bzr bialix-free...06:24
bialixtoday is holiday?06:24
bialixfullermd: yep :-(06:24
* bialix waves on fullermd06:24
* igc waves to fullermd too!06:25
* beuno waves at igc 06:25
igchi beuno!06:25
* fullermd gets a little seasick from all the waving.06:25
bialixmore waves for you: ~~~~~06:25
fullermdOooh...  urrrg...   blech.  This must be how Windows developers feel all the time   :(06:26
bialixrotfl06:28
bialixnot really06:28
igcbialix: ok - bzr-explorer-website now maintained by ~bzr and trunk moved accordingly06:32
bialixigc: thanks06:32
parthmI am getting these gc warning while running some tests. http://pastebin.com/00H7XCn0 ... is this something that I should be worried about?06:38
parthmthis is the test producing the warnings .. http://pastebin.com/KhTkcnV106:40
spivparthm: yes, that's worth worrying about06:44
spivIt indicates that some objects have been locked but not unlocked.06:44
spivWhich 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
parthmspiv: so could this be an issue in test or the code?06:45
spivIn 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
parthmby test i mean test case. and code is feature.06:46
parthmspiv: ok. thanks. will check code.06:46
bialixpoolie: thanks!06:50
bialixhey spiv06:50
spivHey bialix06:51
parthmis '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:52
parthmi am wondering if i should add_cleanup or try/finally.06:53
spivadd_cleanup06:53
spivThere should be something in the dev docs about that06:53
parthmspiv: ok cool. that was the problem. i will add_cleanup to cmd_ignore.06:54
parthmspiv: thanks06:54
spivHmm, the docs do mention @only_raises, but don't seem to have been updated to mention bzrlib.cleanup or Command.add_cleanup06:55
spivJust 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.06:57
parthmspiv: that makes sense. thanks. add_cleanup fixed it.07:00
vilaspiv: quick chat about leaks ?07:54
vilaspiv: or did you EOD already ?07:55
pooliehi there vila08:01
vilapoolie: hey !08:01
spivvila: sure08:05
vilaspiv: 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 thread08:06
vilaspiv: does that make more sense ?08:06
spivvila: if you mean 'while another thread is concurrently performing operations on that socket', sure08:08
vilaspiv: yes, generally listen (Though I avoid that case by faking a connection) or just waiting in a recv() call08:09
spivThat seems fairly clearly a bad thing to do... does our test suite ever try to do that?08:10
vilaspiv: so, next, the smart server create a thread for each client connection and make it a daemonic one, errr, push this subject on the stack08:10
vilaspiv: to reclaim the threads, yes,08:11
vilaspiv: the server collects the threads as connections occur and in stop_server() calls shutdown(RW)08:11
vilathe threads are blocked otherwise waiting for the client to speak08:13
vilathe client sockets are opened, waiting to be used by their respective transport08:13
vilawe don't have a transport.close() to get out of this loop and I don't want to add it before addressing the leaks08:14
vilaI 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 sockets08:16
vilaso I first need a way to completely shutdown the server, including all threads, not relying on the daemonic ones anymore08:16
spivvila: 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
spivOr are you saying something else?08:18
vilathe other side of the socket (the client one),08:18
vilashutdown() + close() actually (I couldn't find a confirmation that one will call the other)08:19
spivSo 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
vilayes08:20
spivOk, that sounds like a bug in our client code to me.08:20
spivPossibly in our test infrastructure for our client code.08:20
vilaspiv: the transport contract says the socket will remain opened so far08:21
spivRight.08:21
vilaand as long as we don't try to manipulate it, there is no point where we can realize it's closed08:22
spivThe fact the contract doesn't facilitate this doesn't contradict my claim ;)08:22
vilaI suspect that python can't either so it can't gc it either08:22
spivThere are a couple of options.08:22
vilaspiv: I wanted to understand if 'bug in our client code' was covering this08:23
spivWell, but in our test infrastructure at least.08:23
spivs/but/bug/08:23
spivWhether 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
vilabacktracking a bit: 'bad thing to do', yes, but what can be the consequences ?08:24
spivSo, actually, I think calling close() in one thread while another does recv() is reasonable.08:25
vilaspiv: no problem with that, as long as the test infra can use it :)08:25
spivIt'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
vilaspiv: 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 context08:25
spivs/for a/for the absence of a/08:26
vilayup, exactly08:26
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
vilaan alternative will be to use timeouts, but I've encountered too many problems with this approach and I'd prefer to avoid it if possible08:27
spivI vote very strongly for steering well clear of Python's socket timeouts.08:28
spivSo there's a fairly cheap thing we could do.08:28
vilaspiv: but close() itself doesn't ensure the other side is notified right ? There may still be data to be transmitted no ?08:28
spivWhich is add a hook point that is called every time ConnectedTransport makes a connection08:28
vilayeah, I overrided transport.get_transport, same result08:29
spivThen the test suite could install a hook function to collect those connection objects, and then close them after every test.08:29
vilayeah, addCleanup(disconnect_transport)08:29
viladisconnect_transport is an ugly hack so far testing for attributes called 'close' or 'disconnect' :-D08:30
spivI 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
spivIt would also be useful as a debugging tool, perhaps.08:31
vilaexactly, this doesn't address what close connection should mean: always close, close only for the last user of the shared connection, etc08:31
spivI 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:32
vilahmm, yeah, a hook is better than overriding get_transport in that case, I'll keep that in mind08:33
spivAnd a hook on "create connection" rather than get_transport in general.08:33
vilasure08:33
vilatransports can be created but never connect08:34
vilanow, about the samrt server itself08:34
vilasmart08:34
vilaa daemonic thread is created for each client connection08:34
vilathis interfere in my leak hunt :)08:35
vilamost of the test use SmartServer_for_testing, but some don't08:35
vilamost of the tests use SmartServer_for_testing, but some don't08:35
vilaI tried to change them but failed, lost in the difference parameters used for __init__ and start_background_thread (from memory)08:36
spivWell, why not do the same thing?08:37
vilacollect threads ?08:37
spivAdd a hook point to bzrlib.smart.server that is invoked for every new thread?08:37
spivThere's already an overall server_started (and server_started_ex :/) hook point.08:38
vilahere you are, thanks, that's the bit I came here for :-)08:38
vilaa bit more work, but definitely the way to go, hooks are good08:39
vila:)08:39
spivI think you only need to invoke it from SmartTCPServer.serve_conn08:40
vilaspiv: a 'connection_started' hook... yes08:40
spivOr perhaps from the target func it uses.08:40
vilathat's the one I override in _for_testing08:40
vilamay be, I have to do the same kind of stuff for http/sftp anyway, I'll try to unify08:41
spivIt's not perfect, as the server does occasionally create other threads08:42
spiv(to handle insert_stream requests)08:42
spivBut I think probably that it will be good enough.08:42
spivvila: btw, jml filed a bug asking about a way to close bzrlib transport connections for launchpad's test suite08:43
vilaha ha, thanks for the tip, I still have a few leaks without explanation so far (but nothing critical anymore)08:43
spivvila: if you do address this be sure to find that bug and let jml know how we're dealing with a similar problem08:44
vilaspiv: 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 it08:44
vilasuccess: the gross hack keep the open files to ~50 instead of >1024 !08:46
vilawith some fallouts for gio and ftp accounting for ~70 failures but that's expected08:46
vilapfew, I see the light !08:47
vilaspiv: thanks for the teddy-bearing, very valuable !08:47
spivvila: nice work!  Glad I could help :)08:48
vilaspiv: by the way, bzrlib.smart.server.SmartTCPServer uses a timeout,08:49
vilaI understand why, yet, it contradicts your recommendation... Why ?08:49
spivBecause the world is imperfect :(08:49
vilagrr, I meant: reading the code I understand why you used it, but why take the risk ?08:50
* spiv looks08:50
spivErk, so it can break out of blocking accept once per second to check if it should stop?  Ugh.08:50
vilaalso, 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
spivGosh I wish we could use Twisted for this stuff.08:51
spivNot that I know of, why do you think so?08:51
vilashooting in the dark here, but in case some weird bug came out of lp, that may be worth looking at08:51
spivThe leaks we've been discussing are client-side.08:52
vilaso far yes, I'm now talking about the smart server creating a daemonic thread in serve_conn08:52
spivI don't recall any bug reports about 'bzr serve' running out of fds.08:52
vilaok, good to know :)08:53
spivWhen the client disconnects that thread will stop.08:53
vilahmm, that's the point where I don't know *when* it will stop08:54
vilaafter all, the client leaks in selftest are kind of a mirror scenario08:54
spivI do know when it will stop.08:55
vilatell me :)08:55
spivIt will stop when it tries to read from the socket and finds it has been disconnected.08:56
vilawhen will it try to read ?08:56
spivAll the time, except when actively working on processing bytes it has already received.08:56
vilathen 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:57
spivWell, 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
vilaguarded by some timeout ?08:58
spivI don't think so.  Timeouts are a risky proposition.08:58
vilano no, not by us, I was thinking by the TCP stack or something08: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)08:59
spivOh, well, some platforms allow you to set a system-wide timeout for checking if a TCP still seems to be alive.09:00
vilahmm, ok, out of scope for today and the hook should be far enough for the tests09:00
spivBut no, we don't do anything about that in bzr.09:00
spivIt would be good to do so, I think.09:00
spivBut judging from the lack of bug reports about it I don't think it's a high priority :)09:01
spivYeah, a hook would be handy there, especially if it is passed the thread object and the socket object.09:01
vilasure, I wanted to mention the idea in case it would light a bulb for you09:01
vilaspiv: for my purposes, both are needed :)09:02
spivBecause 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
spivvila: great :)09:02
vilaspiv: just for fun, have  a look at bzrlib.tests.stub_sftp.SokectListener for the last biggest source of thread leaks :)09:04
spivvila: I've had that fun in the past, I hope you don't mind if I pass on that tonight ;)09:05
vilahehe, np, enjoy your evening :)09:06
=== radoe_ is now known as radoe
peitschieevenin all :)09:58
pooliehi there10:04
peitschiehi :)10:21
AntoineLafI'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 tr12:03
AntoineLaffind a bit more about what might be the source of the problem, I would apreciate.12:03
jelmerAntoineLaf: how big is that single file?12:03
AntoineLafit is a simple settings.php file12:07
tumbleweedhi. I just filed https://bugs.edge.launchpad.net/bzr-rewrite/+bug/588249 anyone got any ideas?12:07
ubot5Launchpad bug 588249 in bzr-rewrite "[regression] Rebase onto previous revision carries merge-metadata (affected: 1, heat: 0)" [Undecided,New]12:07
AntoineLaf12kb12:08
jelmerAntoineLaf: in that case, no idea12:15
jelmerAntoineLaf: you might want to try to see what it's stuck on using strace12:15
AntoineLafjelmer: that's exactly the kind of advice I was looking for :) thx12:16
AntoineLafnow I need to know what strace is... :)12:16
AntoineLafah, okey, I see how this could bring some light on the problem.12:17
jelmertumbleweed: hi12:18
jelmertumbleweed: what do you mean with "will show merge history" ?12:18
tumbleweedjelmer: commit 2 is now a merge commit12:19
=== oubiwann is now known as oubiwann_
jelmertumbleweed: of what exactly?12:19
jelmertumbleweed: also, is this with trunk?12:19
tumbleweedjelmer: http://paste.ubuntu.com/442742/12:19
tumbleweedyes, tested with trunk12:19
tumbleweedit 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:20
=== oubiwann_ is now known as oubiwann
peitschiejelmer: 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
ubot5Launchpad bug 587819 in Bazaar Subversion Plugin "race condition when doing a bzr commit to an svn repo (affected: 1, heat: 6)" [Undecided,New]12:28
jelmertumbleweed: thanks for the bug report12:42
tumbleweedjelmer: np. glad someone can understand it12:42
jelmerpeitschie: sorry, I'm working at the moment12:42
peitschiejelmer: 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 svn12:42
jelmerpeitschie: The only real solution is to lock the root of the tree12:43
peitschiejelmer:... obviously not my first preference :)12:43
peitschiejelmer: 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 state12:43
jelmerpeitschie: one of the alternatives is to remove all bzr revprops from the later revisions12:46
jelmerthat means your history will diverge but you should be able to check out the branch again12:46
peitschiejelmer:  sounds like a plan.  I'll give that a try and see how badly it fails :)12:47
peitschiejelmer: 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
peitschiethanks for your help though... and the otherwise wonderful plugin :)13:38
csgeek_is there something like gitolite/gitosis that exists for bzr?13:49
nDuffcsgeek_, what _are_ gitolite or gitosis?13:49
nDuffcsgeek_, web frontends? PQMs? ...?13:50
nDuffre the former, I think Loggerhead is preferred13:51
csgeek_it allows you to limit what user can write to what using ssh RSA/DSA keys13:51
nDuffahh13:52
csgeek_basically security mechanism for granting user rights to a repo and limit what they can and can't do13:52
csgeek_rathern then relying to unix permission.  Also prevents users from deleting "master" or whatnot13:52
nDuffsee http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/security.html13:52
csgeek_thanks nDuff13:53
nDuffcsgeek_, ...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.13:58
csgeek_PQM = https://launchpad.net/pqm ?14:00
nDuffcsgeek_, and that class of tools, yes; there are a few for git also.14:00
csgeek_I'm familiar with the git tools, it has a few shortcomings, at least work preferes bzr (:14:01
jjannHi. 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
jjannbzr: ERROR: Not a branch: "/path/to/bzr/repo/svn/repo"14:13
jjannbzr st says nothing about that director though, it just shows the removes externals-snapshot14:13
jjannremoved even14:13
jjannany hints on how to get out of this?14:14
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:19
nDuffcsgeek_, there's an experimental colocated branch support plugin, and proper support should eventually show up in a release.14:24
* TresEquis finds bzr's non-colocated branches much easier to work with than the git / hg model14:42
TresEquisespecially with the "shared repository" format14:42
lifeless:)14:45
mgzgaryvdm: re expensive plugins, I bet you're being screwed just by qt import times, it's a big thing15:08
mgzunless you're already very careful about lazy loading?15:08
GaryvdMmgz: we are very carefull about lazy loading.15:09
GaryvdMmgz: it's importing bzrlib.branch15:10
GaryvdMmgz: but I think the method that I used is not very accurate. :-(15:11
mgzmeasuring startup time isn't15:12
mgzyou can do cold startup properly on nix as well, which will give you bigger numbers15:12
mgzwhat was the magic drop-caches command again...15:12
GaryvdMhmm - let me try that15:13
mgzecho 3>/proc/sys/vm/drop_caches15:14
mgzafter a sync.15:14
GaryvdMmgz: do you know what I'm doing wrong here?15:29
GaryvdMhttp://pastebin.org/15:29
GaryvdMhttp://pastebin.org/29807815:29
mgzyour shell doesn't seem to support time taking arguments15:36
mgz(time bzr rocks) 2> plugin_profile.txt15:37
mgzmaybe?15:37
* GaryvdM tries15:37
GaryvdMmgz - that works, but I also want to do time -f %E bzr rocks - What shell should I use?15:38
mgzbash -c "help time"15:40
mgzand see what it offers15:40
mgzotherwise... well, see what else you have installed15:40
GaryvdMhmm - thats very different to "man time"15:41
GaryvdMmgz: got it15:43
GaryvdM /usr/bin/time -ao plugin_profile.txt -f %E bzr rocks15:43
mgza, ha.15:43
csgeek_how do I delete a remote branch?15:46
csgeek_I suppose I can ssh and rm -fr, but is there some mechanism via bzr15:47
mgzjust do the obvious.15:47
jamcsgeek_: 'bzr remove-branch'15:59
jamthough that was added in the 2.2 series16:00
GaryvdMmgz: just sent a mail with the cold cache results.16:00
lfaraoneOne 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:00
ubot5Launchpad bug 587051 in groundcontrol (Ubuntu) "repository incompatibility error message fixing bug in dasher (affected: 1, heat: 10)" [Undecided,New] https://launchpad.net/bugs/58705116:00
GaryvdMlfaraone: The error message could be more friendly...16:02
lfaraoneGaryvdM: okay, what exactly is the problem encountered, and can it be fixed programmatically?16:02
GaryvdMlfaraone: not programmatically16:02
GaryvdMlfaraone: either upgrade lp:~vcs-imports/dasher/trunk, or...16:04
mgzgaryvdm: that's interesting, very different result, presumably more penalty from not lazy loading other needed modules and less from hooks in bzr core16:04
mgzwonder what the search plugin is doing16:04
GaryvdMlfaraone: recreate lp:~alanbell/dasher/bug..... as a --1.14 branch16:05
GaryvdMlfaraone: see bzr help current-formats16:05
GaryvdMlfaraone: You can convert a non-rich-root format to a rich-root format, but not the other way around :-(16:06
=== deryck is now known as deryck[lunch]
GaryvdMhttp://pastebin.org/298236 with search16:14
GaryvdMhttp://pastebin.org/298243 --no-plugins16:14
GaryvdMmgz: ^16:14
GaryvdMmgz: bzrlib.branch, bzrlib.xml416:16
mgzhm, so that is mostly what john was saying in the last mailing list post.16:16
GaryvdMCould be more lazy16:16
mgzthough, making the commands that don't touch branches 100ms faster still seems worthwhile16:17
GaryvdMmgz: Also I want to bring up the gui before bzrlib.branch is imported...16:17
GaryvdMHi vila16:26
vilaGaryvdM: hey !16:27
GaryvdMvila: I'm getting some test failures, an I want check if they are also happening on babune.16:27
GaryvdMvila: But I cant access babune16:27
vilawhere ?16:27
GaryvdMvila: karmic16:27
vilalol, I meant failures where ?16:28
vilaand what do you mean by "can't access" ?16:28
GaryvdMvila: http://pastebin.org/29830016:28
GaryvdMoh16:28
GaryvdMhttp://babune.ladeuil.net:26862/grid16:28
GaryvdMvila^16:29
vilababune is blue and almost sunny16:29
GaryvdMoh - thats the old address16:29
vilawow, wow, wow, that's the old buildbot one, yeah ;)16:30
vilahttp://babune.ladeuil.net:24842/ should be better16:30
vilaGaryvdM: And I thought you were running lucid ?16:30
GaryvdMvila: thaks16:30
GaryvdMvila: lucid on laptop, but not upgraded on the desktop.16:31
vilaGaryvdM: beware, I started keeping various versions here and there and I ended up running babune :-P16:32
GaryvdMvila: Yhea - I'm just lazy to upgrade.16:33
lfaraoneGaryvdM: 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
GaryvdMlfaraone: Yes16:33
GaryvdMlfaraone: bzr also needs a command that you can create a shared repo, in the format that you are going to branch into16:34
GaryvdMlfaraone:  we currently don't have a nice way to do that :-(16:34
GaryvdMvila: any idea why I get these failures, and how to fix: http://pastebin.org/29832716:36
vilaGaryvdM: hmm, that vaguely rings a bell... is it with --no-plugins or anything fancy ?16:38
vilaGaryvdM: anything weird with time or file system there ?16:38
GaryvdMvila: yes16:39
GaryvdMvila: yes --no-plugins16:39
GaryvdMvila: ext4 fs16:40
GaryvdMvila: going to try on the lucid laptop16:40
vilaWhat can I say, using /tmp/testbzr-buzGMO.tmp is asking for trouble, tests don't like being called buggy gizmos even in disguise16:40
vila:)16:40
vilaso, 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 around16:42
GaryvdMvila: ok16:42
vilaincluding running ${TEH_RIGHT_PATH}/bzr st or ${SYSTEM_WIDE_INSTALLED}/bzr st16:42
GaryvdMvila: also fails on lucid laptop16:43
vilarevno ?16:43
GaryvdM527416:43
vilaright, passed tests on babune16:44
vila5274 on trunk right, no local changes ?16:44
GaryvdMyes16:44
GaryvdMhmm - some unknown files. let me try bzr clean-tree and run again16:45
vilaGaryvdM: no !16:46
GaryvdMwhy?16:46
vilawait, 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 bug16:46
vilaGaryvdM: so, put them aside and retry and but I won't hold my breath16:47
GaryvdMvila: I allready did it on the desktop, but it's also failing on the laptop, so we can debug there if needed16:47
* vila reading the test16:48
vilaurgh, one more eager test....16:48
GaryvdMvila: I rm the wt, did a checkout, make and it passes now16:50
GaryvdMvila: Going to debug on the laptop16:50
vilaGaryvdM: anything in your setup related to .... what ?16:50
GaryvdMvila: Sorry - don't understand the question.16:51
vilaI stopped writing when you said you fixed the problem by rm'ing your wt....16:52
GaryvdMok16:52
vilaYou had a dirty wt ?16:52
vilaon both machines ?16:52
GaryvdMyes16:52
vilatell us your dirty secrets will you...16:53
vilawhat did *you* do to that poor wt ?16:53
vilaunresolved conflicts ?16:53
GaryvdMNot sure16:54
GaryvdMThe plot thickens16:56
GaryvdMThe wt was not related.16:56
GaryvdMIf I run ./bzr selftest --no-plugins branch - I get the failures16:57
GaryvdMIf I run ./bzr selftest --no-plugins -s bzrlib.tests.blackbox.test_status.CheckoutStatus.test_branch_status - it passes16:57
GaryvdMvila^16:57
* vila trying16:57
vilawith -s the plugins are loaded16:58
vilaerr, sry, you have --no-plugins there too16:58
vilaeeeerk16:58
vilavada retro satanas failing here, I wasn't there I hear nothing, I saw nothing16:59
=== deryck[lunch] is now known as deryck
vilaso, this smells test isolation17:00
vilamaybe a hook was added recently in this area and was not registered in b.h.known_hooks ?17:00
GaryvdMvila: There was a BZR_PDB for tests, but I can't find it now.17:00
GaryvdMvila: Maybe it was in my imagination ...17:02
vilahmm, no I think there is one17:02
vilaBZR_TEST_PDB17:03
GaryvdMvila: Thanks. btw where did you find that?17:03
vilaemacs...17:04
vila:-P17:04
vilaI searched for PDB in bzrlib/tests/__init__.py17:04
GaryvdMok17:04
vilaGaryvdM: can you run qblame bzrlib/status.py and tell me if th revnos are truncated for you too17:05
GaryvdMvila: Yes17:07
GaryvdMvila: 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 shown17:08
mgzbut see bug 50407017:09
ubot5Launchpad bug 504070 in testtools "testtools change broke BZR_TEST_PDB (affected: 1, heat: 8)" [Wishlist,Triaged] https://launchpad.net/bugs/50407017:09
GaryvdMvila: taking into account font metrics, I'm worried that it will be slow.17:09
vilaGaryvdM: just give me a way to resize interactively :)17:09
GaryvdMvila: yes17:10
vilaGaryvdM: do you often run ~3000 tests in a single selftest ?17:14
vilaGaryvdM: did your failing runs ended mentioning a high number of leaking tests ?17:15
GaryvdMvila: no - I want to make some imports lazy in bzrlib.branch - so I want to test lots of things17:15
vilathe no was for the ~3000 ?17:16
GaryvdMYes17:16
GaryvdMvila: 17 non-main threads were left active in the end.17:16
vilahow many leaking tests ?17:16
GaryvdMbzrlib.tests.blackbox.test_branch.TestBranchStacked.test_branch_stacked_from_smart_server is leaking threads among 13 leaking tests.17:17
vilanext line17:17
vilaerr, what 13 only, lier :)17:17
GaryvdMvila: bzr: interrupted - I'll run it again17:17
j0rdI'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 thinking17:18
vilahaaa, I got 591 leaking tests and 166 non-main thread left active17:18
mgzhey, that's better than 160017:18
vilaon top of that, there are may sockets left open, so you may be experiencing a 'Too Many Files Open' exception that is silently swallowed17:18
vilamgz: that's for trunk :)17:19
GaryvdMj0rd: Here is a page with good reasons: http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html17:19
j0rdGaryvdM: reading it now17:19
j0rdGaryvdM: i was interested in real users expereiences as well17:19
vilaonce I finished implementing all my pending tricks, I should be close to 0 unexplained thread leaks17:19
j0rdi use ubuntu as well, which is another selling point of bzr, but other than that....i've never really heard of people using it17:20
mgzif you can get the working set of a full test run back down to 200MB rather than 1GB I'll be very happy17:20
vilamgz: 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:20
vilamgz: no idea about that yet, first things first :)17:21
* vila back to hacking17:21
kostja_osipovj0rd: we use bazaar quite extensively here at MySQL, moved from BitKeeper.17:21
kostja_osipovI'd say it's a pretty good tool, although we do have internal advocates with git17:22
kostja_osipovthe main selling point for me with bzr would be that you can get paid support from the vendor for it.17:22
j0rdkostja_osipov: i assume you have used the others as well "cvs, svn, git?" which is the stream i'm coming from.17:22
kostja_osipovsvn was out of the question when we migrated, being a "better cvs"17:23
kostja_osipovgit was high on the list, mainly because of its speed.17:23
=== nlisgo_ is now known as nlisgo
j0rdkostja_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 documentation17:23
kostja_osipovbut git wasn't as mature as it is now when we migrated, back in 200817:23
vilaGaryvdM: 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 :-D17:23
kostja_osipovj0rd: well, that's launchpad platform, it's way more than just bzr17:24
mgz<kostja_osipov> 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 now17:24
j0rdkostja_osipov: i'm aware of that, it's something I'll need17:24
kostja_osipovwe 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 launchpad17:24
GaryvdMvila: ack17:24
kostja_osipovmgz: we needed Windows support.17:24
mgzwhich git still doesn't have.17:25
mgzrunning half a unix system underneath it doesn't count.17:25
kostja_osipovmgz: when you choose a tool for a large open source project, you want all platform to be well supported.17:25
kostja_osipovand bzr was better than others in that.17:25
mgzbazaar has improved much more in the last two years than the other vcses17:25
kostja_osipovmgz: well, I think it's better now than before. I haven't been looking17:25
j0rdease 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 problems17:26
j0rdanother reason I'm looking towards bzr right now17:26
mgzyou can get a pre-packaged msys with your git now, it is still a sucky option17:26
GaryvdMvila: 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_osipovmgz: 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_osipovand in some parts it's of course better than bk17:26
mgzyup, there's a long way to go all round.17:27
kostja_osipovj0rd: how big is your project?17:27
vilaGaryvdM: yes, a blackbox test runs with stdout/stderr/stdin redirected, subprocess is not a requirement and we try to avoid them17:27
kostja_osipovhow many people work on it?17:27
j0rdkostja_osipov: many small projects, for one off clients17:28
vilaGaryvdM: stdout/stdin being redirected, pdb can't be used17:28
j0rdkostja_osipov: about 1-3 months in lenght each17:28
j0rdkostja_osipov: drupal development. Ubercart uses bzr as well17:28
j0rdand i do mostly ubercart work17:28
j0rdso another selling point17:28
kostja_osipovI'd say if you're under 500 000 and 5 years of active history, you won't notice much of bzr drawbacks.17:29
kostja_osipovat least they are not apparent to me on that scale.17:30
j0rdkostja_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 built17:30
kostja_osipovmy issue was with performance and with bzr file-ids...17:30
kostja_osipovand some gui quirks... I'd like the gui to be more flexible.17:30
kostja_osipovbut otherwise... does the job.17:30
j0rdkostja_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 easily17:31
GaryvdMkostja_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:31
kostja_osipovI use gtk but I miss some very specific interface that was good in BK17:32
kostja_osipovgotta go (dinner)17:32
j0rdkostja_osipov: thanks for your insight, very helpful17:33
GaryvdMj0rd: It is very easy to run your own loggerhead. (http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk2a/files is loggerhead)17:33
vilakostja_osipov: tell us at least what you're missing, we're holding our breath !17:33
vilakostja_osipov: :)17:33
GaryvdMkostja_osipov: If you don't mind qt to much, give qbzr a try.17:34
* GaryvdM plugs away shamelessly17:34
kostja_osipovI will. I'm missing bk sccstool to be precise17:35
kostja_osipovwhere 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_osipovreally need to go17:36
GaryvdMkostja_osipov: sounds like bzr qlog17:37
jjannI 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 luck17:39
jjannok, deleting .bzrmeta/externals completely helped17:53
GaryvdMvila: test results: http://pastebin.org/29879618:32
GaryvdMvila: The problem is caused by trace.is_quite() returning True. I'm going to log a bug.18:33
GaryvdMAh - Allready loged. 57999618:36
GaryvdMbug 57999618:36
ubot5Launchpad bug 579996 in Bazaar "test_status failure on trunk (revno 5227) (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/57999618:36
Abhijeethi all18:45
Abhijeetour company currently using jazz clearcase server from IBM18:45
Abhijeetwe are thinking to replacing this with new SVC..18:45
AbhijeetOur servers are based on HPUX os.18:46
Abhijeetso is BZR well supported on it?18:46
maxbHPUX is pretty rare. Your chances of finding someone who knows about it on IRC are fairly slim18:49
maxbBut if it can run Python and a decent C compiler, chances are good18:49
Abhijeethpux has it's own compilers.18:59
exarkunbzr locks seem to last across reboots on Windows19:58
exarkunThat's a bit unfortunate, eh?19:58
GaryvdMexarkun: you just need to break the lock with bzr break-lock20:02
exarkunGaryvdM: I know.  But I don't see why I should need to.20:02
bialixheya20:03
GaryvdMHi bialix20:03
bialixI have question about pqm setup20:04
bialixactually 2 questions20:04
bialix1) Does example in the HACKING.txt is still correct? it talking about sftp and b-v.o URLs so it seems pretty outdated20:04
bialix2) 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:05
bialixhi Garyvdm20:06
GaryvdMbialix: yes HACKING.txt does seam out of date. From my locations.conf: http://pastebin.org/29916620:07
GaryvdMbialix: re question 2 - It does not only apply to windows...20:09
GaryvdMexarkun: 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:14
GaryvdMexarkun: 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:15
exarkunGaryvdM: That's probably true.  bzr should use a lock that gets reset across reboots, instead of whatever it uses now.20:16
exarkunI filed a bug report, https://bugs.launchpad.net/bzr/+bug/58843120:17
ubot5Launchpad bug 588431 in Bazaar "bzr locks persist across reboots (affected: 1, heat: 6)" [Undecided,New]20:17
GaryvdMok20:17
bialixexarkun: I don't think so20:26
=== nlisgo_ is now known as nlisgo
bialixGaryvdM: oh, nice, thanks for the example20:27
exarkunbialix: 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
bialixexarkun: the problem with limbo is a known bug20:27
bialixexarkun: everything else is require more intelligence than bzr has right now20:28
bialixit's not so hard to run break-lock, is it?20:28
exarkunYes, it is.20:28
bialixGaryvdM: cool, I was not sure I can use lp: style urls20:29
exarkunIf I were actually the agent running "bzr checkout", then maybe it wouldn't be so hard to manually break the lock.20:29
exarkunBut I'm not.  An automated build system is.20:29
bialixyep20:30
GaryvdMbialix: yes, except for the submit branch.20:31
exarkunSo 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
exarkunSo, 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:31
bialixyes20:32
=== oubiwann is now known as oubiwann_
=== nlisgo_ is now known as nlisgo
=== oubiwann_ is now known as oubiwann
bialixGaryvdm: I want a pony^W qpqm-submit command. And planning to do so tomorrow20:48
=== nlisgo_ is now known as nlisgo
GaryvdMbialix: :-)20:49
GaryvdMbialix: I want to look at our start up time on windows20:49
bialixbtw, I've started dogfooding bzr-explorer every day20:50
bialixit needs to be improved20:50
bialixone things that bother me: we need to invent a way to add "edit file" command to treewidget context menu20:50
bialixGaryvdM: cool20:51
GaryvdMI 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
GaryvdMbialix: like you laptop.20:52
GaryvdM*your20:52
bialixhmm20:52
GaryvdMOpen = edit file20:52
bialixno20:54
bialixopen is launched file20:54
GaryvdMbialix: 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
bialixso open for python file is just launched its execution20:54
bialixGaryvdM: really? I'm ever don't know if there is up-to-date instructions20:55
bialixwhy you need installer?20:55
GaryvdMbialix: 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
bialixyou don't need installer for this20:56
bialixyou can build bzr.exe with `python setup.py py2exe` command20:57
bialixand there is one place n setup.py where you can control creation of library.zip20:57
GaryvdMbialix: re Edit File - maybe show the options for the different edit applications registerd in windows, like windows explorer?20:57
GaryvdMoh - ok20:58
bialixGaryvdM: if you run bzr-explorer -- then you can see edit action (icon of paper with pen) which opens selected file in treewidget in the editor20:58
bialixwe need a way to mirror this action in treewidget20:59
bialixallow explorer to inject this action20:59
bialixIIRC there is bug report on this20:59
=== nlisgo_ is now known as nlisgo
bialixGaryvdM: which instructions scare you?21:00
GaryvdMbialix: bzr.dev/doc/developers/win32_build_setup.txt21:02
GaryvdMThats just to install the dependencies.21:02
jamGaryvdM: what is your alternative to library.zip ? A loose tree of files?21:03
GaryvdMThen you have to get all the plugins21:03
jami'm pretty sure that would be slower21:03
GaryvdMjam: yes21:03
jam.zip already has an index at the back21:03
jamand the actual content is stored uncompressed21:03
jamAnd navigating the python import path is a real pain on Windows21:03
jam(and so is trying to measure cold-start performance)21:04
jamGaryvdM: I thought bialix had done some testing to show that the pre-built installer was quite a bit faster than running from source21:05
jambut it has been a while21:05
GaryvdMjam: apparently you can do   options = {"py2exe": {"skip_archive":1}}21:05
GaryvdM 21:05
bialixjam: it was faster for me, at least on FAT3221:05
bialixbut I can't say for sure about NTFS21:05
bialixhi jam, btw21:06
GaryvdMI think that a py2exe exe probably does not scan the installed python paths, which would explain why it's faster.21:07
bialixGaryvdm: those could be simpler a bit: http://wiki.bazaar.canonical.com/BzrWin32Installer21:07
bialixGaryvdM: actually py2exed application has only library.zipin sys.path21:07
bialixGaryvdM: actually py2exed application has only library.zip in sys.path21:08
GaryvdMbialix: Yes, thats what I was trying to say21:08
GaryvdMbialix: thanks for the better doc.21:08
bialixGaryvdM: they're out-of-date a bit21:09
bialixfeel free to blame21:09
GaryvdMjam, bialix: we don't need MS Visual Studio for tbzr any more?21:09
bialixno, we need21:10
bialixmaybe you can skip tbzr?21:10
* bialix is about to going offline21:11
GaryvdMI thought that req was removed. :-(21:12
bialixhow fullermd said? rest is for wimps? so I am21:12
bialix~~~21:12
jamGaryvdM: You need at least the 'light' version, but I've never actually worked out how to do it21:14
jamnaoki was good enough to figure out how to use express edition + an sdk21:14
jambut as bialix mentioned, that is mostly just for the tbzr extension21:14
jamI thought you had access to Desolation, though (the win32 build host)21:15
GaryvdMjam: No :-(21:15
aarfeick_I have a question on bug tracking... is anyone here knowledgable about it?21:27
mkanataarfeick_: Bug tracking in general, or bug-tracking with launchpad?21:29
aarfeick_Well, I wrote my own bug tracker (as an exercise)21:30
aarfeick_I developed a URL scheme to close bugs21:30
aarfeick_My commits indicate the URL of the fix, but I don't think Bazaar is actually resolving that URL21:30
aarfeick_Any ideas why?21:31
jelmeraarfeick_: What do you mean with your commits indicate the URL of the fix?21:31
mkanataarfeick_: The bzr bugtracking support doesn't do anything to the bug-tracker.21:32
mkanataarfeick_: 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 config21:32
aarfeick_I see21:32
aarfeick_I thought the point was to actually apply the fix using that URL21:32
jelmeraarfeick_: no, it just tracks that a particular bug was fixed by a particular revision21:33
aarfeick_I see...21:33
aarfeick_I suppose I'd have to write a hook to do anything about it?21:33
mkanataarfeick_: Yeah.21:33
jelmeraarfeick_: in launchpad's case it scans branches that are pushed for this revision proprety21:34
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
mkanataarfeick_: You could have the bug-tracker scan the VCS.21:35
aarfeick_Oh... so it could scan the logs for the fix statement21:36
aarfeick_My current implementation of the tracker is web-based so it can be used by other developers21:36
aarfeick_So it would not be so simple21:36
lifelessmoin21:36
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 bug21:46
aarfeick_Is there a *good* way to do this in Python?21:46
exarkunBy "visits" do you mean "issues an HTTP GET to"?21:47
lifelessaarfeick_: a post commit hook could do "bzrlib.transport.get_transport(bugfix_url).get('.')" or you could use httplib/httplib2/twisted's getPage etc etc21:48
aarfeick_exarkun: yes, an HTTP GET.21:49
exarkunYea, what lifeless said.21:49
exarkunThere's like a million Python libraries for that. :)21:49
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 PHP21:50
GaryvdMjam: Is there a reason bzrlib.errors one big file? It is quite costly to import.21:52
GaryvdMdito for bzrlib.builtins21:53
GaryvdMI'm trying to delay the importing of bzrlib.errors. It's a wack a mole game....21:55
lifelessGaryvdM: they are22:02
lifelessGaryvdM: I've considered a few things, like putting them one-per-error in separate py files22:03
lifelessmore realistic to do that for builtins to start with, I think.22:03
GaryvdMlifeless: ok22:06
lifelessGaryvdM: however22:12
lifelessGaryvdM: for builtins.py we have to load it for most commands22:12
lifelessGaryvdM: for errors, if we catch *any* exception, we have to load it.22:12
lifelessSo lazy loading is a misleading tool for performance improvements here.22:13
lifelessThe key thing is, how much code do we load *doing a users operation*22:13
lifelessand how much code do we *use* to do that operation22:13
GaryvdMlifeless: My objective is to get those things to only import after I have got a qbzr window up22:14
GaryvdMlifeless: I know it's just delaying the inevitable...22:15
GaryvdMlifeless: I've made some progress. I can now import bzrlib.branch with out importing bzrlib.repofmt.pack_repo :-)22:16
TresEquisugh, just had bzr revert --forget-merge still leave my sandbox hosed (due to conflicts)22:17
TresEquisI would expect all the conflicts to get washed away by the revert22:17
lifelessthe difference is stuff we can work on22:17
lifelessGaryvdM: how do users invoke qbzr ?22:18
GaryvdMlifeless: Either the command line, or tbzr, or bzr explorer22:18
lifelessdetails!22:18
lifelessgimme gimme details22:18
GaryvdMbzr qlog22:19
lifelessok22:19
lifelessso22:19
lifelesshow do you feel about 'qbzr log'22:19
GaryvdMlifeless: hmm - I don't know22:20
GaryvdMlifeless: I'll think about that.22:21
lifelessthat would make it trivial to avoid builtins.py - you wouldn't want all the bzr commands loaded *anyway*22:21
lifelessand similarly errors.py would only need commands.py and options.py to be audited22:21
lifelessa small tweak to the command lookup invocation code in your frontend would make 'qbzr log' load 'qlog' as the command object22:22
lifelessand you can register the stock bzr command providers after you're in your mainloop22:22
lifeless[if you want them at all, that is]22:23
lifelessif you're not calling into cmd_foo objects, then you don't need to register them *at all*22:23
GaryvdMlifeless: I don't think builtins is a problem  - I'll check22:23
GaryvdMlifeless: The other way to solve the problem is a central hook registry as per mailing list discussion.22:24
lifelessthat won't solve the problem22:25
lifelessbuiltins.py, which you mentioned at :53 is *already* demand loaded by hooks22:25
lifelessyou'll get precisely 0.0 time saves from hook infrastructure changes for builtins.py22:26
IslandUsurperTresEquis, 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 remain22:27
lifelessTresEquis: 'bzr revert' - resets files and merge info22:27
lifelessTresEquis: 'bzr revert .' - rests just files22:27
lifelessTresEquis: 'bzr revert --forget-merges' - resets just merge info22:28
GaryvdMlifeless: ok - sorry the builtins comment was just an observation. The bigger problem is plugins importing bzrlib.branch to register hook.22:28
lifelessGaryvdM: thats not a problem for the command line22:28
GaryvdMlifeless: yes22:29
lifelessGaryvdM: And there is a lot of stuff in branch.py we should move into a format package22:29
lifelesslike we did for repository22:29
lifelessthat would make branch.py cheaper22:29
lifelessnot saying that the hook changes might help22:30
lifelessbut for branch.py it only defers stuff22:30
lifelessbetter to avoid it completely; and we have 4 formats or so, only need the code for one.22:30
GaryvdMlifeless: Yes, thats what I've been trying to do (make import bzrlib.branch cheaper) (maybe with the wrong approach)22:30
TresEquislifeless:  thanks, that helps22:31
lifelessGaryvdM: I'd like to see the following made cheaper "using a branch"22:33
lifelessGaryvdM: think whole-operation costs, not import costs.22:33
lifelessthat would benefit *everything*22:33
GaryvdMlifeless: ack22:33
* lifeless hands the furball back22:34
GaryvdMhttp://bazaar.launchpad.net/~garyvdm/bzr/delay_imports/revision/527622:34
GaryvdMlifeless: ^ that makes import bzrlib.branch not import  bzrlib.repofmt.pack_repo22:36
GaryvdMjon$yd22:38
GaryvdMdarn - wrong window22:39
lifelesslol22:39
GaryvdMtime to change lots of passwords...22:41
exarkunGaryvdM: To different things, this time.22:46
GaryvdMexarkun: My brain wont cope with that22:46
exarkunGaryvdM: That's okay.  Use technology.22:46
GaryvdMexarkun: Important things like bank are different22:47
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:13
aarfeickI am having trouble using iter_bugs() in revision.py...23:22
lifelessyes?23:23
GaryvdMlifeless: 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:24
lifelessGaryvdM: I'm not really all that interested in profile-imports23:25
lifelessGaryvdM: I'm interested in 'time bzr st'23:25
GaryvdMok23:26
lifelesswith (say) a 20K file tree23:26
lifelessor 100K if your machine is too fast to detect changes on 20K23:26
lifelessGaryvdM: profile imports and similar are tools to direct performance effort, but they are poor proxies for actual time-spent.23:26
lifelessGaryvdM: remember that importing all of bzr and plugins etc on modern machines is < 0.5 seconds23:27
lifelessGaryvdM: oh also, if working on just getting-started speed, also time bzr st on very small trees23:28
lifelessyou'll have some chance of making the import time dominate23:28
GaryvdMlifeless: yes - I've been timing bzr st on small trees, but not large trees23:28
lifelessthe risk with large trees will be near-zero if you're not changing code in loops23:29
lifelessbut 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 within23:29
GaryvdMlifeless: I'm also testing with cold cache, and warm cache23:29
lifelessyes23:30
lifelessjelmer: have you seen hydrazine?23:35
jelmerlifeless: yes23:36
lifelessI'd love it if you use it23:36
lifelessbecause we could start generalising and pulling its features up into lp proper23:36
lifelessyou don't have to23:37
lifelessjust saying23:37
jelmerlifeless: I do use it, I contributed some trivial fixes IIRC :-)23:38
lifelessjelmer: ah! perhaps you have a stale branch :)23:39
jelmerlifeless: which features are you thinking of though?23:39
jelmerI've mostly used bugclient so far23:39
lifelessfeed-pqm23:39
pooliehi jam23:41
pooliehi lifeless, GaryvdM, jelmer23:41
lifelesshey23:41
GaryvdMHi poolie23:42
GaryvdMHow come doing a status on a 2a branch imports xml code. I thought that 2a used bencode rather than xml.23:54
* GaryvdM sees if making that lazy makes a difference.23:55
lifelessGaryvdM: better to not load it, than to make it lazy23:58
lifelessGaryvdM: lazy loading has given us some really nasty structures23:58

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!