[00:08] it needs to be lazier or something [00:08] or resolve to both ids and then handle one being absent [00:08] yeah [00:08] the latter I think [00:08] though I think it has the order backwards currently [00:09] so cat -r x FOO [00:09] can resolve to two files [00:09] should it cat both? [00:09] no, I don't think so [00:10] I think it should cat FOO at x if possible [00:10] with a way to say cat current file-id of FOO at x [00:10] possibly falling back to that if the path FOO isn't in x [00:10] 'Morning'. [00:10] hello Odd_Bloke [00:10] evenin' [00:10] how's pqm/ [00:11] hey poolie [00:11] That falls back into 'cat [like log] should be able to take a file-id'... [00:11] fullermd: yeah, logs even more complex I think, but we should provide a way to specify what you want [00:12] log's I mean [00:12] poolie: Not bad. I had a bit of a lull over the past few days, but I'm back on track now. [00:13] I intend to spend today working on XMLRPC stuff, mostly testing. [00:16] Odd_Bloke: 'today' ?? [00:16] i see your sleep cycles are still crazy :) [00:16] mwhudson: Yeah, I'm not entirely sure what's going on there. :p [00:16] Sounds perfectly reasonable to me :p [00:17] When I'm like this and want to get work done, I find it easiest to just assume I'm shifted by n hours and act as if it's a normal day. [00:17] Odd_Bloke: http://www.xkcd.com/448/ [00:17] Odd_Bloke: i guess you're around melbourne currently? [00:17] perth tomorrow? [00:20] I think I'm probably just off Australia's west coast ATM. [00:20] * Odd_Bloke --> breakfast [00:24] lol [00:24] hgweb is a windows trojan [00:25] 'evening * [00:28] hi jelmer [00:35] poolie: so, last we spoke about groupcompress you were hazy; are you less hazy now ? [00:36] thumper: ping [00:37] lifeless: is the graphs-in-hgweb something you have to turn on or something? [00:37] lifeless: i don't see it on http://hg.mozilla.org/index.cgi/mozilla-central/shortlog (for example) [00:37] lifeless: yes? [00:38] mwhudson: its a recent feature; back at europython CERN there was a beta branch [00:38] mwhudson: but core didn't like the performance [00:38] lifeless: ok [00:38] its based on my merge_sort code :P [00:38] thumper: echannel sorry [00:38] well haha [00:39] lifeless: presumably it doesn't merge sort the whole graph the whole time though? [00:39] shurg [00:40] or at least, the code I saw at EP was done by grabbing merge_sort [00:40] lifeless: that was a good summary, thanks [00:40] lifeless: i'd like to make sure sometime before we commit to it there is a format specification separate from the code [00:41] shocking! [00:41] (do you mean like the EBNF's I write for the other low level things I create?) [00:41] well if you merge sorted the revision graph of bzrlib on every request, performance would be terrible [00:41] I have some infrastructure I want to write [00:41] :) [00:42] like that [00:42] yeah [00:43] there isn't one at this point because its got a lot of room for complete changes at the deepest level [00:43] i think it would be good to do that as a review into /doc/developers fairly early on [00:43] not as a fait accompli with teh code [00:43] for instance, using a hacked xdelta rather than a custom compressor [00:44] poolie: uhm, that sounds like committing to it before its done; I'd rather not do that. Why not just discuss on the list like we do for other conceptual changes [00:46] i don't mean it has to be frozen before the code is done [00:46] obviously that would be inefficient [00:46] just that it might be worth having some of that discussion around a spec, rather than around either the code or just an informal description [00:47] I'm clearly missing something [00:48] I'm off doing research at the moment [00:49] aiming to decide on what spec will work best [00:49] i'll try again [00:49] where best is 'the C version will be fast enough that we are happy for a few years' [00:49] i'd like a spec to be reviewed before it is too late to change the code [00:50] but without waiting for the code to stop changing [00:50] and the code changes change the spec [00:51] Whatever, we're spinning. I'll send in a doc/ patch before I send in the main code if that will make you happy, but unlike other changes where we can clearly describe what we want, this is deep down under an already defined interface [00:51] I don't understand what process hole doing this will solve. [00:54] possible conversation bug: I'm assuming you just want me to send in docs early, not to change my actual development process for thisl [00:54] as my development process has for a very long time had plenty of discussion on list and circulation of ideas so its not a design-bomb & code-bomb situation [00:55] if you want my development process to change; perhaps we should talk about what is going wrong there rather? [00:55] s/ rather// === emgent_ is now known as emgent === mw is now known as mw|out [02:45] beuno: btw, bzr-search now has '-foo' support [02:45] beuno: but it doesn't quite play well with suggestions; TODO [03:11] lifeless: that was a good explanation of your concerns about .bzrrules, i thought [03:12] thanks [03:19] jelmer: ping [03:19] lifeless, pong [03:19] do you have any thoughts on how we can get jstowers productive again ? [03:20] lifeless, I'm working on getting those file text revids stored in file properties [03:21] lifeless, as to the current broken push, I think that's only really fixable by dumping the svn repo and reloading it without those properties (or adding the text-revid properties manually once bzr-svn supports them) [03:21] jelmer: would it be possible to script that last step for him ? [03:21] I think that would be really nice to do if we can :) [03:22] lifeless: In theory we could though it's a lot more work than just fixing it manually [03:22] since we don't have any functions for modifying svn dump files [03:24] well [03:24] we can't easily dump and load the svn, its gnomes production svn [03:25] is there some other way, perhaps rebasing rather than merging, or something [03:26] lifeless, well, rebasing rather than merging will prevent this problem from happening again while the fix isn't in yet [03:26] it doesn't help with the existing repository though [03:27] well I was suggesting dumping the existing bzr repo [03:27] doing a fresh conversion from current svn; and rebasing his personal branches [03:27] ah, yeah, that'll fix it as well [03:29] actually, I think just starting out with a fresh branch and pulling from his personal branch will do it [03:29] since that shouldn't try to fetch any ghosts, right? [03:29] right [03:33] do you want to note this in the bug (he is subscribed right?) [03:39] hi all [03:40] hi igc [03:40] igc: I sent the mail we discussed [03:40] hi lifeless [03:40] lifeless: thanks, I'm reading through email now [03:40] igc: btw - re subclassing WorkingTreeFormat4 [03:41] I think its better to invert the relationship - to bring in newer formats as superclasses [03:41] why's that? [03:42] so that our latest-and-greatest is higher up the hierarchy [03:42] (if they are not siblings that is) [03:42] lifeless: is performance the driver? [03:42] I mean - having format4(format3), format3(format2) etc gets quite convoluted and makes it hard to move format2 out to a plugin [03:43] logically, a new format adds things [03:43] ah - ok [03:44] so when there is a hierarchy, having format2(format3), format3(format4), format4(object) means that the oldest code is a leaf node and more easily removable [03:44] often though we'll actually have something like [03:44] beuno: hello [03:44] format2(xmlformat), format3(xmlformat) format4(dirstateformat), format5(dirstateformat), xmlformat(dirstateformat) [03:44] dirstateformat(object) [03:44] or soemthing like that - more a tree [03:45] bug the goal over time has to be maintenance of the code base, not representing the order things got added to the code :) [03:45] agreed === jaypipes_mysql is now known as jaypipes [04:21] mwhudson, howdy [04:22] beuno: i'm hacking at a themed directory listing [04:22] beuno: but it's turning into real hackery [04:22] I was about to say "yay", but..oh. [04:23] Peng_: red greed refactor, right? [04:23] mwhudson, ah, yes, I did that once too [04:23] it got so ugly I reverted [04:23] heh [04:25] lifeless, ah, I see [04:26] - doesn't play well with suggestions? [04:26] (cool, btw) [04:27] yeah, doing Robert -xml in the box gives no suggestions [04:28] its a search bug not loggerhead: [04:28] search/trunk$ bzr search -s Robert -- -xml [04:28] Suggestions: [] [04:28] /search/trunk$ bzr search Robert -- -xml | wc -l [04:28] 46 [04:30] lifeless, ah, I see [04:31] I don't think it's a feature you'd use with autocomplete anyways [04:31] why not ? [04:31] even though it is a bug you'd want to fix [04:32] well, if you already know that much, you'll probably search anyways [04:32] perhaps [04:32] still, ELATER [04:32] yeao [04:32] autocomplete currently suggest searches [04:32] I'd like to look into providing results [04:32] exactly [04:33] mmm [04:33] I have a few ideas for search which may be cool [04:33] could be interesting [04:33] I'd love to be able to arrow key down into the suggestions [04:33] yes, me too. It's a tricky one though [04:34] hey, just an easy one, is it safe to run two dedicated servers, one read-only and another with write access, both for the same repo ? [04:34] works on google ;) [04:34] gerel: yes thats fine [04:34] lifeless: thank, you're a bzr dever ? :-) (just curious) [04:34] yeah, damn google makes everybody look bad [04:35] gerel: yes [04:35] beuno: actually I meant 'why not see what they do :P' [04:35] * gerel just tried www.cuil.com [04:35] lifeless, I know how to do it, it's just hard :) [04:36] big bubble on search engines these days [04:36] lifeless: many thanks for your help [04:36] beuno: ah, what makes it hard? [04:36] I could peak and see if it's easily re-usable, but google isn't usually some place you can copy javascript off [04:36] gerel: well, people have been trying for what, a decade now? to dethrone google [04:37] I suspect it needs some radical new approach rather than just tweaks [04:37] lifeless, keyboard keys and browsers don't play well, and re-inventing widgets like drop down lists is complicated too [04:37] (like pagerank was when it came out) [04:37] What sort of message should I use with 'bzr record'? I'm not sure what I'm meant to be describing. [04:37] yeap, re-write parts of the javascript is needed [04:38] Odd_Bloke: you are recording the: list of threads, the tip of each thread [04:38] * igc lunch, then reviewing jam's MultiWalker patch [04:39] lifeless, either way, it's on my ToDo list. I want to make search really useful on LH [04:39] :-> [04:40] Odd_Bloke: you should record before you push; and the message would be something about where you are up to in the overall shape of things - like a commit message is for an individual branch [04:40] lifeless: Cool, thanks. [04:42] lifeless: i sent a pretty small patch for bug 252428, would appreciate if you could look at that [04:42] Launchpad bug 252428 in bzr "stacking must always grab full inventories" [Critical,New] https://launchpad.net/bugs/252428 [04:43] lifeless: its just we need a big web classifier that keep us from the irrelevant data that makes us waste time, i thing in 20 years the inet as we know it, totally free and public, will change [04:43] lifeless: the big corps want to control us all, kill the p2p and what not [04:43] gerel, reminds me of the boltcutters a security engineer friend used to keep in his drawer [04:44] gerel: depends on which corp :) big telcos _love_ p2p - more money [04:44] wow amazing [04:45] gtk just fixed an incredibly long standing bug [04:50] lifeless: thanks [04:50] lifeless: hah, maybe but they'll earn more if they sell you a web pack with 20 sites too :-) [04:52] lifeless: we better start mesh networks with Access points [04:53] well, mesh is fun [04:53] we have quite some engineering and political discussions to make it viable large scale [04:53] lifeless: yeah, and it'll be the only free thing you'll be able to do :-P [04:54] lifeless: where ? [04:54] mwhudson, ah, yes, I did that once too it got so ugly I reverted [04:54] poolie: was it a bug you filed? [04:54] yes [04:55] i may have been filing a dupe [04:55] basically it is that you can only click a button after your mouse moves into it [04:55] if it appears under your mouse, or changes from disabled to sensitive while it's under your mouse, you can't [04:55] you have to move out and back in [04:55] sounds trivial; apparently it was really hard [04:56] gerel: well, we need enough spectrum reserved; we need solid p2p dns (security,robustness, etc); we need solid adhoc networking across the entire mesh etc etc - if you decentralise the entire stack its a lot of work, but thats what the end goal is IMO [04:56] I bet it's nice to put things like that to bed [04:56] i have been getting and deleting "me too" mail for the last N years [04:56] poolie: :> [04:56] lifeless: correct, i guess we'll be forced to [04:56] I have the odd bug like that [05:00] lifeless: I'll follow up with him once I fix this bug (which should be < 1 day now) [05:00] beuno: i see what you mean now :) [05:01] lifeless, Odd_Bloke: Is PQM using lp or bb for merge requests now? [05:07] i thought it was using lp [05:07] jelmer: cool [05:07] pqm is using a bit of btoh [05:26] just experimenting with bzr...i think i found a small bug [05:26] http://pastebin.com/m543a24ad [05:27] mwhudson, lol [05:27] maybe we should generate that different [05:27] and not hack around it [05:27] gambler: what are you saying is a bug ? [05:28] it looks like it replaced the ~ with a unicode or something [05:28] thats URL escaping [05:28] ssh usually expands that [05:28] ah ok [05:29] it will be handled correctly [05:44] beuno: well, there is some grottiness in filesystem.py that should be cleaned up i guess [05:58] * beuno wonders why he doesn't get email when people ask questions about loggerhead [06:01] * beuno wanders off to bed [06:02] beuno: i just set up ~loggerhead-team as an answers contact a few minutes ago [06:03] mwhudson, aah, ok. That makes sense [06:03] I'll unsubscribe [06:03] so now launchpad will send us even more mail!!! [06:03] shouldn't that be the default? [06:03] i have no idea [06:04] oh, wait [06:04] I think I activated answers [06:05] a few days ago, trying to change something else [06:05] sorry :) [06:05] ah :) [06:05] damn people are fast to find stuff [06:05] good idea [06:05] but strange that the owner isn't a contact by default [06:07] it is [06:07] anyway, off to be for real this time [06:07] mwhudson, if you get anywhere with the templating, let me know [06:07] I'm planning on working on that tomorrow [06:07] beuno: ok, there's a branch on lp [06:08] not that it should incentive you to drop it in any way :) [06:08] i'm not going to be working on it much more... [06:08] (today, anyway) [06:08] but yeah, funny questions like [06:08] "should there be tabs?" [06:08] beuno: g'night [06:09] mwhudson, yeah, sometimes giving karma to people fires back :p [06:09] night! [06:09] * Odd_Bloke --> lunch [06:09] beuno: Sleep well! [06:10] Odd_Bloke, you too, whenever it is you'll be doing that [06:10] mwhudson, LP won't let me get your branch [06:10] beuno@beuno-laptop:~/bzr_devel/loggerhead$ bzr branch lp:~mwhudson/loggerhead/themed-directory-listing [06:10] bzr: ERROR: Not a branch: "bzr+ssh://beuno@bazaar.launchpad.net/~mwhudson/loggerhead/themed-directory-listing/" [06:10] I suppose because it's private [06:11] beuno: the push hasn't finished yet [06:11] ah [06:11] I still don't trust LP when it says it hasn't. It will take a while to regain it's trust [06:12] * beuno closes laptop === `6og is now known as Kamping_Kaiser [07:18] poolie: hi [07:30] poolie: jam has re-posted a patch for BranchBuilder after you voted tweak. Did you want to re-review it or would you like me to do it? === thekorn_ is now known as thekorn [07:53] I'm trying to write a test for a plugin that uses XMLRPC. Do we have something in bzrlib that will allow me to capture any POST requests made to a URL? [07:53] the smartserver code demonstrates a post handler [07:55] Ah, OK, that is working, I was getting confused by something else. [08:06] igc, hi [08:06] jml, hi to you too [08:07] spiv, ping? === abentley1 is now known as abentley [08:07] spiv, i saw your patch for 251871 was tweaked, is it in now, or ok to go in? [08:07] igc, i'll re-read it but you're welcome to if you want to [08:07] it should not be very complex or controversial [08:08] poolie: I'm looking at markh's changes to setup.py so I may not get to it [08:08] .. today [08:08] np === yacc_ is now known as yacc [08:19] poolie: It's not in yet, I'm tweaking it at the moment (adding a test) [08:19] poolie: the fix itself isn't being changed by the tweak though. [08:31] ok thanks [08:32] poolie: just fired the tweaked version to PQM, in fact. [08:43] did it really drop my merge? :/ [09:02] night all [09:02] night ian [09:02] sleep well [09:07] spiv, if you're still here [09:07] pqm says my stuff is merged but i can't see it in trunk [09:07] what do you see as the last rev of bzr.dev? [09:12] "(robertc) Fix bug 150438 - dirstate corruption due to invalid..." [09:12] Launchpad bug 150438 in bzr "corrupt inventory deltas are not detected by dirstate" [High,Fix released] https://launchpad.net/bugs/150438 [09:13] poolie: ^ [09:14] mm thanks [09:14] maybe pqm has gone for the weekend :/ [09:18] me too [09:19] :) [09:19] lifeless: well, if you want to poke it sometime that would be good but there's no rush on my account [09:22] let me finish this hardy upgrade [09:22] evms headaches === sabdf1 is now known as sabdfl [09:28] poolie: No actual code on that repo tests reorg thing? [09:28] do you mean no patch [09:29] Yah. [09:30] thanks [09:30] BB should really say 'you silly silly boy' not 'accepted' [09:31] It's not really paying attention right now; it's off cavorting with pqm for the weekend :p [09:56] night all [10:50] Yikes! Loggerhead's SQL cache got corrupted, leaving most pages as 500 errors for...I dunno how long. [10:51] Wow, good timing! It only happened like 10 minutes ago. [10:52] Poor Googlebot. It even got one 503 error when I shut down LH while fixing this. [11:11] what bzr+http protocol requires on the server side? [11:12] * gour is dissussing in #ghc about possibility to use bzr for ghc [11:13] hey gour [11:13] http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#serving-bazaar-with-fastcgi [11:14] ta [11:14] there may be other ways [11:14] basically you need to make your http server hand of some requests to a bzr process [11:15] ghc is seriously considering switch from darcs, but, unfortunately, bzr is not considered seriously enough [11:15] yeah, I saw the wiki page [11:15] james_w: have you seen irc log as well? [11:15] no, I haven't [11:16] it's referenced there, iirc [11:17] http://hackage.haskell.org/trac/ghc/attachment/wiki/IRC_Meetings/ghc-metting-2008-07-23.log [11:18] thanks [11:19] james_w: i wrote (on #ghc) to JaffaCake (he is one of main ghc devs) about bzr...sending blog about mysql adoption etc. [11:20] it would be nice of some bzr dev could address some of their issues 'cause wiki page has some strong Pro points [11:21] cherry-picking is the one [11:25] push push push. after 3 months of bzr use for our internal projects let me thank all bzr developers. kudos! push push push. [11:30] 178 [17:22] bos: [11:30] 179 git has about 2x the number of users of hg, and only one significant project uses bzr. [11:30] 180 [17:23] JaffaCake: [11:30] 181 that rules out bzr, I think [11:30] right, that's why i mentioned mysql to JaffaCake [11:30] the mysql link probably helped there then, thanks [11:31] and soon bzr will have more source code in it than any of the others, just that it won't be used by the projects themselves all the time [11:31] * gour thinks bzr is the most balanced dvcs...and still improving performance [11:33] Could the ghc devs dry out different DVCSes to see which one they like best? [11:34] heh, it does not always go like that [11:35] Err, try out* [11:37] some people on #ghc complain about problems building on mac osx [11:43] I have just realised that I included an mp3 file in my bzr repo a few commits ago, so sharing it over http is going to be slow. What's the best way to remove it from the packs? [11:43] gour: that is a little bit unclear? [11:43] gour: they do know of 10.5 and 10.4 dmgs at http://bazaar-vcs.org/Download ? [11:46] LarstiQ: it looks it was some 10.4 issue and/or tiger & python-2.5 [11:47] gour: I don't think 10.4 has python 2.5 [11:48] if they use the OS X installers it should include it [11:48] Pilky: they wrote "python 2.5 is broken on tiger". i don't know anything about osx versioning [11:48] Tiger is 10.4, Leopard is 10.5 [11:49] heh, funny [11:50] just tell them to use the OS X installers unless they have a specific need to build [11:50] yeah Apple is cat crazy with OS X [11:50] Cheetah, Puma, Jaguar, Panther, Tiger, Leopard, Snow Leopard for 10.0 - 10.6 [11:50] it seemed they were able to install it [11:50] Surely they'll run out eventually... [11:50] lol [11:51] probably by 11.0 [11:51] Have to start taking more obscure ones.... lynx, ocelot, cerval.. onyx? [11:51] well there's still Lion available [11:51] Though I'm very disappointed there's no Lion yet [11:51] but I think most people are waiting for Tabby Cat [11:51] Or maybe they're saving that for the ultimate conclusion, the pinacle, the peak in perfection. :( [11:51] :) [11:51] heh [11:51] what about Monkeys? [11:52] well they managed to push Lion off for a while with Snow Leopard [11:52] I can see Ocelot possibly being used, I think lynx has some issues with trademarks or something [11:52] Liger! [11:53] heh [11:53] Sphin/X [11:53] I just need to get enough money to get a new ADC account so I can get my hands on Snow Leopard, it's meant to have some pretty cool stuff in it. Unfortunately I don't currently have £300 spare :p [12:02] I have a repository with 2 branches, if I want bazaar to execute a script when files have been comitted to a specific branch (for all users), what do I need to do? [12:02] hi Jayzee [12:03] james_w: hello there [12:03] you can write a plugin that provides a post_commit hook and activate it for the branch that you want [12:03] I got that but I suppose the plugin is not supposed to be in my home then? [12:04] since I'm not the only comitter [12:04] if you want it more general than running "bzr commit" in that specific branch, e.g. to run after pushing to that branch, then you can use a "post_branch_change_tip" hook, or whatever it is called [12:04] no, it will need to be in bzrlib/plugins wherever bzr is installed [12:04] or in every users' ~/.bazaar/plugins/ [12:04] or you could do something with BZR_PLUGIN_DIR [12:05] Jayzee: is this a centralized setup? [12:05] I can't find anything abut post_branch [12:05] Jayzee: what does your script do? there might be a better way [12:05] yes, It's one machine with 2 developers comitting [12:06] Jayzee: post_change_branch_tip [12:06] basically I would like to do a "bzr export ..." when stuff has been comitted to stable-branch [12:06] but as alsuren said, what is it you are trying to achieve? [12:06] ah, thanks LarstiQ [12:06] right [12:07] I would like code for our website to be copied to www-root when changes are being made to stable branch [12:07] * LarstiQ nods at Jayzee [12:07] Jayzee: post_change_branch_tip sounds like the right thing then [12:08] you *could* do it from cron, but post_change_branch_tip would work nicely [12:08] one more thing, do I really need to write a plugin in python?? [12:08] I'm more confortable in php/bash [12:08] comfortable [12:09] I don't know what the status of the shell hooks work is [12:10] Jayzee: this plugin should not be too difficult [12:10] let me have a look for you [12:10] thx james [12:16]