| lifeless | it needs to be lazier or something | 00:08 |
|---|---|---|
| lifeless | or resolve to both ids and then handle one being absent | 00:08 |
| james_w | yeah | 00:08 |
| james_w | the latter I think | 00:08 |
| james_w | though I think it has the order backwards currently | 00:08 |
| lifeless | so cat -r x FOO | 00:09 |
| lifeless | can resolve to two files | 00:09 |
| lifeless | should it cat both? | 00:09 |
| james_w | no, I don't think so | 00:09 |
| james_w | I think it should cat FOO at x if possible | 00:10 |
| james_w | with a way to say cat current file-id of FOO at x | 00:10 |
| james_w | possibly falling back to that if the path FOO isn't in x | 00:10 |
| Odd_Bloke | 'Morning'. | 00:10 |
| poolie | hello Odd_Bloke | 00:10 |
| james_w | evenin' | 00:10 |
| poolie | how's pqm/ | 00:10 |
| james_w | hey poolie | 00:11 |
| fullermd | That falls back into 'cat [like log] should be able to take a file-id'... | 00:11 |
| james_w | fullermd: yeah, logs even more complex I think, but we should provide a way to specify what you want | 00:11 |
| james_w | log's I mean | 00:12 |
| Odd_Bloke | poolie: Not bad. I had a bit of a lull over the past few days, but I'm back on track now. | 00:12 |
| Odd_Bloke | I intend to spend today working on XMLRPC stuff, mostly testing. | 00:13 |
| mwhudson | Odd_Bloke: 'today' ?? | 00:16 |
| mwhudson | i see your sleep cycles are still crazy :) | 00:16 |
| Odd_Bloke | mwhudson: Yeah, I'm not entirely sure what's going on there. :p | 00:16 |
| fullermd | Sounds perfectly reasonable to me :p | 00:16 |
| Odd_Bloke | 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 |
| mwhudson | Odd_Bloke: http://www.xkcd.com/448/ | 00:17 |
| mwhudson | Odd_Bloke: i guess you're around melbourne currently? | 00:17 |
| mwhudson | perth tomorrow? | 00:17 |
| Odd_Bloke | I think I'm probably just off Australia's west coast ATM. | 00:20 |
| * Odd_Bloke --> breakfast | 00:20 | |
| lifeless | lol | 00:24 |
| lifeless | hgweb is a windows trojan | 00:24 |
| jelmer | 'evening * | 00:25 |
| lifeless | hi jelmer | 00:28 |
| lifeless | poolie: so, last we spoke about groupcompress you were hazy; are you less hazy now ? | 00:35 |
| lifeless | thumper: ping | 00:36 |
| mwhudson | lifeless: is the graphs-in-hgweb something you have to turn on or something? | 00:37 |
| mwhudson | lifeless: i don't see it on http://hg.mozilla.org/index.cgi/mozilla-central/shortlog (for example) | 00:37 |
| thumper | lifeless: yes? | 00:37 |
| lifeless | mwhudson: its a recent feature; back at europython CERN there was a beta branch | 00:38 |
| lifeless | mwhudson: but core didn't like the performance | 00:38 |
| mwhudson | lifeless: ok | 00:38 |
| lifeless | its based on my merge_sort code :P | 00:38 |
| lifeless | thumper: echannel sorry | 00:38 |
| mwhudson | well haha | 00:38 |
| mwhudson | lifeless: presumably it doesn't merge sort the whole graph the whole time though? | 00:39 |
| lifeless | shurg | 00:39 |
| lifeless | or at least, the code I saw at EP was done by grabbing merge_sort | 00:40 |
| poolie | lifeless: that was a good summary, thanks | 00:40 |
| poolie | lifeless: i'd like to make sure sometime before we commit to it there is a format specification separate from the code | 00:40 |
| lifeless | shocking! | 00:41 |
| lifeless | (do you mean like the EBNF's I write for the other low level things I create?) | 00:41 |
| mwhudson | well if you merge sorted the revision graph of bzrlib on every request, performance would be terrible | 00:41 |
| lifeless | I have some infrastructure I want to write | 00:41 |
| poolie | :) | 00:41 |
| poolie | like that | 00:42 |
| lifeless | yeah | 00:42 |
| lifeless | there isn't one at this point because its got a lot of room for complete changes at the deepest level | 00:43 |
| poolie | i think it would be good to do that as a review into /doc/developers fairly early on | 00:43 |
| poolie | not as a fait accompli with teh code | 00:43 |
| lifeless | for instance, using a hacked xdelta rather than a custom compressor | 00:43 |
| lifeless | 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:44 |
| poolie | i don't mean it has to be frozen before the code is done | 00:46 |
| poolie | obviously that would be inefficient | 00:46 |
| poolie | 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:46 |
| lifeless | I'm clearly missing something | 00:47 |
| lifeless | I'm off doing research at the moment | 00:48 |
| lifeless | aiming to decide on what spec will work best | 00:49 |
| poolie | i'll try again | 00:49 |
| lifeless | where best is 'the C version will be fast enough that we are happy for a few years' | 00:49 |
| poolie | i'd like a spec to be reviewed before it is too late to change the code | 00:49 |
| lifeless | but without waiting for the code to stop changing | 00:50 |
| lifeless | and the code changes change the spec | 00:50 |
| lifeless | 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 |
| lifeless | I don't understand what process hole doing this will solve. | 00:51 |
| lifeless | 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 |
| lifeless | 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:54 |
| lifeless | if you want my development process to change; perhaps we should talk about what is going wrong there rather? | 00:55 |
| lifeless | s/ rather// | 00:55 |
| === emgent_ is now known as emgent | ||
| === mw is now known as mw|out | ||
| lifeless | beuno: btw, bzr-search now has '-foo' support | 02:45 |
| lifeless | beuno: but it doesn't quite play well with suggestions; TODO | 02:45 |
| poolie | lifeless: that was a good explanation of your concerns about .bzrrules, i thought | 03:11 |
| lifeless | thanks | 03:12 |
| lifeless | jelmer: ping | 03:19 |
| jelmer | lifeless, pong | 03:19 |
| lifeless | do you have any thoughts on how we can get jstowers productive again ? | 03:19 |
| jelmer | lifeless, I'm working on getting those file text revids stored in file properties | 03:20 |
| jelmer | 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 |
| lifeless | jelmer: would it be possible to script that last step for him ? | 03:21 |
| lifeless | I think that would be really nice to do if we can :) | 03:21 |
| jelmer | lifeless: In theory we could though it's a lot more work than just fixing it manually | 03:22 |
| jelmer | since we don't have any functions for modifying svn dump files | 03:22 |
| lifeless | well | 03:24 |
| lifeless | we can't easily dump and load the svn, its gnomes production svn | 03:24 |
| lifeless | is there some other way, perhaps rebasing rather than merging, or something | 03:25 |
| jelmer | lifeless, well, rebasing rather than merging will prevent this problem from happening again while the fix isn't in yet | 03:26 |
| jelmer | it doesn't help with the existing repository though | 03:26 |
| lifeless | well I was suggesting dumping the existing bzr repo | 03:27 |
| lifeless | doing a fresh conversion from current svn; and rebasing his personal branches | 03:27 |
| jelmer | ah, yeah, that'll fix it as well | 03:27 |
| jelmer | actually, I think just starting out with a fresh branch and pulling from his personal branch will do it | 03:29 |
| jelmer | since that shouldn't try to fetch any ghosts, right? | 03:29 |
| lifeless | right | 03:29 |
| lifeless | do you want to note this in the bug (he is subscribed right?) | 03:33 |
| igc | hi all | 03:39 |
| lifeless | hi igc | 03:40 |
| lifeless | igc: I sent the mail we discussed | 03:40 |
| igc | hi lifeless | 03:40 |
| igc | lifeless: thanks, I'm reading through email now | 03:40 |
| lifeless | igc: btw - re subclassing WorkingTreeFormat4 | 03:40 |
| lifeless | I think its better to invert the relationship - to bring in newer formats as superclasses | 03:41 |
| igc | why's that? | 03:41 |
| lifeless | so that our latest-and-greatest is higher up the hierarchy | 03:42 |
| lifeless | (if they are not siblings that is) | 03:42 |
| igc | lifeless: is performance the driver? | 03:42 |
| lifeless | I mean - having format4(format3), format3(format2) etc gets quite convoluted and makes it hard to move format2 out to a plugin | 03:42 |
| igc | logically, a new format adds things | 03:43 |
| igc | ah - ok | 03:43 |
| lifeless | 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 |
| lifeless | often though we'll actually have something like | 03:44 |
| mwhudson | beuno: hello | 03:44 |
| lifeless | format2(xmlformat), format3(xmlformat) format4(dirstateformat), format5(dirstateformat), xmlformat(dirstateformat) | 03:44 |
| lifeless | dirstateformat(object) | 03:44 |
| lifeless | or soemthing like that - more a tree | 03:44 |
| lifeless | 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 |
| igc | agreed | 03:45 |
| === jaypipes_mysql is now known as jaypipes | ||
| beuno | mwhudson, howdy | 04:21 |
| mwhudson | beuno: i'm hacking at a themed directory listing | 04:22 |
| mwhudson | beuno: but it's turning into real hackery | 04:22 |
| Peng_ | I was about to say "yay", but..oh. | 04:22 |
| mwhudson | Peng_: red greed refactor, right? | 04:23 |
| beuno | mwhudson, ah, yes, I did that once too | 04:23 |
| beuno | it got so ugly I reverted | 04:23 |
| mwhudson | heh | 04:23 |
| beuno | lifeless, ah, I see | 04:25 |
| beuno | - doesn't play well with suggestions? | 04:26 |
| beuno | (cool, btw) | 04:26 |
| lifeless | yeah, doing Robert -xml in the box gives no suggestions | 04:27 |
| lifeless | its a search bug not loggerhead: | 04:28 |
| lifeless | search/trunk$ bzr search -s Robert -- -xml | 04:28 |
| lifeless | Suggestions: [] | 04:28 |
| lifeless | /search/trunk$ bzr search Robert -- -xml | wc -l | 04:28 |
| lifeless | 46 | 04:28 |
| beuno | lifeless, ah, I see | 04:30 |
| beuno | I don't think it's a feature you'd use with autocomplete anyways | 04:31 |
| lifeless | why not ? | 04:31 |
| beuno | even though it is a bug you'd want to fix | 04:31 |
| beuno | well, if you already know that much, you'll probably search anyways | 04:32 |
| lifeless | perhaps | 04:32 |
| lifeless | still, ELATER | 04:32 |
| beuno | yeao | 04:32 |
| beuno | autocomplete currently suggest searches | 04:32 |
| beuno | I'd like to look into providing results | 04:32 |
| lifeless | exactly | 04:32 |
| lifeless | mmm | 04:33 |
| beuno | I have a few ideas for search which may be cool | 04:33 |
| lifeless | could be interesting | 04:33 |
| lifeless | I'd love to be able to arrow key down into the suggestions | 04:33 |
| beuno | yes, me too. It's a tricky one though | 04:33 |
| gerel | 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 |
| lifeless | works on google ;) | 04:34 |
| lifeless | gerel: yes thats fine | 04:34 |
| gerel | lifeless: thank, you're a bzr dever ? :-) (just curious) | 04:34 |
| beuno | yeah, damn google makes everybody look bad | 04:34 |
| lifeless | gerel: yes | 04:35 |
| lifeless | beuno: actually I meant 'why not see what they do :P' | 04:35 |
| * gerel just tried www.cuil.com | 04:35 | |
| beuno | lifeless, I know how to do it, it's just hard :) | 04:35 |
| gerel | big bubble on search engines these days | 04:36 |
| gerel | lifeless: many thanks for your help | 04:36 |
| lifeless | beuno: ah, what makes it hard? | 04:36 |
| beuno | 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 |
| lifeless | gerel: well, people have been trying for what, a decade now? to dethrone google | 04:36 |
| lifeless | I suspect it needs some radical new approach rather than just tweaks | 04:37 |
| beuno | lifeless, keyboard keys and browsers don't play well, and re-inventing widgets like drop down lists is complicated too | 04:37 |
| lifeless | (like pagerank was when it came out) | 04:37 |
| Odd_Bloke | What sort of message should I use with 'bzr record'? I'm not sure what I'm meant to be describing. | 04:37 |
| beuno | yeap, re-write parts of the javascript is needed | 04:37 |
| lifeless | 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:38 | |
| beuno | lifeless, either way, it's on my ToDo list. I want to make search really useful on LH | 04:39 |
| lifeless | :-> | 04:39 |
| lifeless | 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 |
| Odd_Bloke | lifeless: Cool, thanks. | 04:40 |
| poolie | lifeless: i sent a pretty small patch for bug 252428, would appreciate if you could look at that | 04:42 |
| ubottu | Launchpad bug 252428 in bzr "stacking must always grab full inventories" [Critical,New] https://launchpad.net/bugs/252428 | 04:42 |
| gerel | 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 |
| gerel | lifeless: the big corps want to control us all, kill the p2p and what not | 04:43 |
| poolie | gerel, reminds me of the boltcutters a security engineer friend used to keep in his drawer | 04:43 |
| lifeless | gerel: depends on which corp :) big telcos _love_ p2p - more money | 04:44 |
| poolie | wow amazing | 04:44 |
| poolie | gtk just fixed an incredibly long standing bug | 04:45 |
| poolie | lifeless: thanks | 04:50 |
| gerel | lifeless: hah, maybe but they'll earn more if they sell you a web pack with 20 sites too :-) | 04:50 |
| gerel | lifeless: we better start mesh networks with Access points | 04:52 |
| lifeless | well, mesh is fun | 04:53 |
| lifeless | we have quite some engineering and political discussions to make it viable large scale | 04:53 |
| gerel | lifeless: yeah, and it'll be the only free thing you'll be able to do :-P | 04:53 |
| gerel | lifeless: where ? | 04:54 |
| mwhudson | <beuno> mwhudson, ah, yes, I did that once too <beuno> it got so ugly I reverted | 04:54 |
| lifeless | poolie: was it a bug you filed? | 04:54 |
| poolie | yes | 04:54 |
| poolie | i may have been filing a dupe | 04:55 |
| poolie | basically it is that you can only click a button after your mouse moves into it | 04:55 |
| poolie | if it appears under your mouse, or changes from disabled to sensitive while it's under your mouse, you can't | 04:55 |
| poolie | you have to move out and back in | 04:55 |
| poolie | sounds trivial; apparently it was really hard | 04:55 |
| lifeless | 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 |
| pickscrape | I bet it's nice to put things like that to bed | 04:56 |
| poolie | i have been getting and deleting "me too" mail for the last N years | 04:56 |
| lifeless | poolie: :> | 04:56 |
| gerel | lifeless: correct, i guess we'll be forced to | 04:56 |
| lifeless | I have the odd bug like that | 04:56 |
| jelmer | lifeless: I'll follow up with him once I fix this bug (which should be < 1 day now) | 05:00 |
| mwhudson | beuno: i see what you mean now :) | 05:00 |
| jelmer | lifeless, Odd_Bloke: Is PQM using lp or bb for merge requests now? | 05:01 |
| poolie | i thought it was using lp | 05:07 |
| lifeless | jelmer: cool | 05:07 |
| lifeless | pqm is using a bit of btoh | 05:07 |
| gambler | just experimenting with bzr...i think i found a small bug | 05:26 |
| gambler | http://pastebin.com/m543a24ad | 05:26 |
| beuno | mwhudson, lol | 05:27 |
| beuno | maybe we should generate that different | 05:27 |
| beuno | and not hack around it | 05:27 |
| lifeless | gambler: what are you saying is a bug ? | 05:27 |
| gambler | it looks like it replaced the ~ with a unicode or something | 05:28 |
| lifeless | thats URL escaping | 05:28 |
| gambler | ssh usually expands that | 05:28 |
| gambler | ah ok | 05:28 |
| lifeless | it will be handled correctly | 05:29 |
| mwhudson | beuno: well, there is some grottiness in filesystem.py that should be cleaned up i guess | 05:44 |
| * beuno wonders why he doesn't get email when people ask questions about loggerhead | 05:58 | |
| * beuno wanders off to bed | 06:01 | |
| mwhudson | beuno: i just set up ~loggerhead-team as an answers contact a few minutes ago | 06:02 |
| beuno | mwhudson, aah, ok. That makes sense | 06:03 |
| beuno | I'll unsubscribe | 06:03 |
| mwhudson | so now launchpad will send us even more mail!!! | 06:03 |
| beuno | shouldn't that be the default? | 06:03 |
| mwhudson | i have no idea | 06:03 |
| beuno | oh, wait | 06:04 |
| beuno | I think I activated answers | 06:04 |
| beuno | a few days ago, trying to change something else | 06:05 |
| beuno | sorry :) | 06:05 |
| mwhudson | ah :) | 06:05 |
| beuno | damn people are fast to find stuff | 06:05 |
| mwhudson | good idea | 06:05 |
| mwhudson | but strange that the owner isn't a contact by default | 06:05 |
| beuno | it is | 06:07 |
| beuno | anyway, off to be for real this time | 06:07 |
| beuno | mwhudson, if you get anywhere with the templating, let me know | 06:07 |
| beuno | I'm planning on working on that tomorrow | 06:07 |
| mwhudson | beuno: ok, there's a branch on lp | 06:07 |
| beuno | not that it should incentive you to drop it in any way :) | 06:08 |
| mwhudson | i'm not going to be working on it much more... | 06:08 |
| mwhudson | (today, anyway) | 06:08 |
| mwhudson | but yeah, funny questions like | 06:08 |
| mwhudson | "should there be tabs?" | 06:08 |
| mwhudson | beuno: g'night | 06:08 |
| beuno | mwhudson, yeah, sometimes giving karma to people fires back :p | 06:09 |
| beuno | night! | 06:09 |
| * Odd_Bloke --> lunch | 06:09 | |
| Odd_Bloke | beuno: Sleep well! | 06:09 |
| beuno | Odd_Bloke, you too, whenever it is you'll be doing that | 06:10 |
| beuno | mwhudson, LP won't let me get your branch | 06:10 |
| beuno | beuno@beuno-laptop:~/bzr_devel/loggerhead$ bzr branch lp:~mwhudson/loggerhead/themed-directory-listing | 06:10 |
| beuno | bzr: ERROR: Not a branch: "bzr+ssh://beuno@bazaar.launchpad.net/~mwhudson/loggerhead/themed-directory-listing/" | 06:10 |
| beuno | I suppose because it's private | 06:10 |
| mwhudson | beuno: the push hasn't finished yet | 06:11 |
| beuno | ah | 06:11 |
| beuno | I still don't trust LP when it says it hasn't. It will take a while to regain it's trust | 06:11 |
| * beuno closes laptop | 06:12 | |
| === `6og is now known as Kamping_Kaiser | ||
| jml | poolie: hi | 07:18 |
| igc | 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? | 07:30 |
| === thekorn_ is now known as thekorn | ||
| Odd_Bloke | 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 |
| lifeless | the smartserver code demonstrates a post handler | 07:53 |
| Odd_Bloke | Ah, OK, that is working, I was getting confused by something else. | 07:55 |
| poolie | igc, hi | 08:06 |
| poolie | jml, hi to you too | 08:06 |
| poolie | spiv, ping? | 08:07 |
| === abentley1 is now known as abentley | ||
| poolie | spiv, i saw your patch for 251871 was tweaked, is it in now, or ok to go in? | 08:07 |
| poolie | igc, i'll re-read it but you're welcome to if you want to | 08:07 |
| poolie | it should not be very complex or controversial | 08:07 |
| igc | poolie: I'm looking at markh's changes to setup.py so I may not get to it | 08:08 |
| igc | .. today | 08:08 |
| poolie | np | 08:08 |
| === yacc_ is now known as yacc | ||
| spiv | poolie: It's not in yet, I'm tweaking it at the moment (adding a test) | 08:19 |
| spiv | poolie: the fix itself isn't being changed by the tweak though. | 08:19 |
| poolie | ok thanks | 08:31 |
| spiv | poolie: just fired the tweaked version to PQM, in fact. | 08:32 |
| poolie | did it really drop my merge? :/ | 08:43 |
| igc | night all | 09:02 |
| poolie | night ian | 09:02 |
| poolie | sleep well | 09:02 |
| poolie | spiv, if you're still here | 09:07 |
| poolie | pqm says my stuff is merged but i can't see it in trunk | 09:07 |
| poolie | what do you see as the last rev of bzr.dev? | 09:07 |
| Odd_Bloke | "(robertc) Fix bug 150438 - dirstate corruption due to invalid..." | 09:12 |
| ubottu | Launchpad bug 150438 in bzr "corrupt inventory deltas are not detected by dirstate" [High,Fix released] https://launchpad.net/bugs/150438 | 09:12 |
| Odd_Bloke | poolie: ^ | 09:13 |
| poolie | mm thanks | 09:14 |
| poolie | maybe pqm has gone for the weekend :/ | 09:14 |
| lifeless | me too | 09:18 |
| poolie | :) | 09:19 |
| poolie | lifeless: well, if you want to poke it sometime that would be good but there's no rush on my account | 09:19 |
| lifeless | let me finish this hardy upgrade | 09:22 |
| lifeless | evms headaches | 09:22 |
| === sabdf1 is now known as sabdfl | ||
| fullermd | poolie: No actual code on that repo tests reorg thing? | 09:28 |
| poolie | do you mean no patch | 09:28 |
| fullermd | Yah. | 09:29 |
| poolie | thanks | 09:30 |
| poolie | BB should really say 'you silly silly boy' not 'accepted' | 09:30 |
| fullermd | It's not really paying attention right now; it's off cavorting with pqm for the weekend :p | 09:31 |
| poolie | night all | 09:56 |
| Peng_ | Yikes! Loggerhead's SQL cache got corrupted, leaving most pages as 500 errors for...I dunno how long. | 10:50 |
| Peng_ | Wow, good timing! It only happened like 10 minutes ago. | 10:51 |
| Peng_ | Poor Googlebot. It even got one 503 error when I shut down LH while fixing this. | 10:52 |
| gour | what bzr+http protocol requires on the server side? | 11:11 |
| * gour is dissussing in #ghc about possibility to use bzr for ghc | 11:12 | |
| james_w | hey gour | 11:13 |
| james_w | http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#serving-bazaar-with-fastcgi | 11:13 |
| gour | ta | 11:14 |
| james_w | there may be other ways | 11:14 |
| james_w | basically you need to make your http server hand of some requests to a bzr process | 11:14 |
| gour | ghc is seriously considering switch from darcs, but, unfortunately, bzr is not considered seriously enough | 11:15 |
| james_w | yeah, I saw the wiki page | 11:15 |
| gour | james_w: have you seen irc log as well? | 11:15 |
| james_w | no, I haven't | 11:15 |
| gour | it's referenced there, iirc | 11:16 |
| gour | http://hackage.haskell.org/trac/ghc/attachment/wiki/IRC_Meetings/ghc-metting-2008-07-23.log | 11:17 |
| james_w | thanks | 11:18 |
| gour | james_w: i wrote (on #ghc) to JaffaCake (he is one of main ghc devs) about bzr...sending blog about mysql adoption etc. | 11:19 |
| gour | it would be nice of some bzr dev could address some of their issues 'cause wiki page has some strong Pro points | 11:20 |
| gour | cherry-picking is the one | 11:21 |
| fog | push push push. after 3 months of bzr use for our internal projects let me thank all bzr developers. kudos! push push push. | 11:25 |
| james_w | 178 [17:22] bos: | 11:30 |
| james_w | 179 git has about 2x the number of users of hg, and only one significant project uses bzr. | 11:30 |
| james_w | 180 [17:23] JaffaCake: | 11:30 |
| james_w | 181 that rules out bzr, I think | 11:30 |
| gour | right, that's why i mentioned mysql to JaffaCake | 11:30 |
| james_w | the mysql link probably helped there then, thanks | 11:30 |
| james_w | 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:31 | |
| Peng_ | Could the ghc devs dry out different DVCSes to see which one they like best? | 11:33 |
| gour | heh, it does not always go like that | 11:34 |
| Peng_ | Err, try out* | 11:35 |
| gour | some people on #ghc complain about problems building on mac osx | 11:37 |
| alsuren | 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 |
| LarstiQ | gour: that is a little bit unclear? | 11:43 |
| LarstiQ | gour: they do know of 10.5 and 10.4 dmgs at http://bazaar-vcs.org/Download ? | 11:43 |
| gour | LarstiQ: it looks it was some 10.4 issue and/or tiger & python-2.5 | 11:46 |
| Pilky | gour: I don't think 10.4 has python 2.5 | 11:47 |
| Pilky | if they use the OS X installers it should include it | 11:48 |
| gour | Pilky: they wrote "python 2.5 is broken on tiger". i don't know anything about osx versioning | 11:48 |
| Pilky | Tiger is 10.4, Leopard is 10.5 | 11:48 |
| gour | heh, funny | 11:49 |
| Pilky | just tell them to use the OS X installers unless they have a specific need to build | 11:50 |
| Pilky | yeah Apple is cat crazy with OS X | 11:50 |
| Pilky | Cheetah, Puma, Jaguar, Panther, Tiger, Leopard, Snow Leopard for 10.0 - 10.6 | 11:50 |
| gour | it seemed they were able to install it | 11:50 |
| LeoNerd | Surely they'll run out eventually... | 11:50 |
| gour | lol | 11:50 |
| Pilky | probably by 11.0 | 11:51 |
| LeoNerd | Have to start taking more obscure ones.... lynx, ocelot, cerval.. onyx? | 11:51 |
| Pilky | well there's still Lion available | 11:51 |
| LeoNerd | Though I'm very disappointed there's no Lion yet | 11:51 |
| Pilky | but I think most people are waiting for Tabby Cat | 11:51 |
| LeoNerd | Or maybe they're saving that for the ultimate conclusion, the pinacle, the peak in perfection. :( | 11:51 |
| LeoNerd | :) | 11:51 |
| Pilky | heh | 11:51 |
| gour | what about Monkeys? | 11:51 |
| Pilky | well they managed to push Lion off for a while with Snow Leopard | 11:52 |
| Pilky | I can see Ocelot possibly being used, I think lynx has some issues with trademarks or something | 11:52 |
| LarstiQ | Liger! | 11:52 |
| Pilky | heh | 11:53 |
| fullermd | Sphin/X | 11:53 |
| Pilky | 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 | 11:53 |
| Jayzee | 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 |
| james_w | hi Jayzee | 12:02 |
| Jayzee | james_w: hello there | 12:03 |
| james_w | you can write a plugin that provides a post_commit hook and activate it for the branch that you want | 12:03 |
| Jayzee | I got that but I suppose the plugin is not supposed to be in my home then? | 12:03 |
| Jayzee | since I'm not the only comitter | 12:04 |
| james_w | 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 |
| james_w | no, it will need to be in bzrlib/plugins wherever bzr is installed | 12:04 |
| james_w | or in every users' ~/.bazaar/plugins/ | 12:04 |
| james_w | or you could do something with BZR_PLUGIN_DIR | 12:04 |
| LarstiQ | Jayzee: is this a centralized setup? | 12:05 |
| Jayzee | I can't find anything abut post_branch | 12:05 |
| alsuren | Jayzee: what does your script do? there might be a better way | 12:05 |
| Jayzee | yes, It's one machine with 2 developers comitting | 12:05 |
| LarstiQ | Jayzee: post_change_branch_tip | 12:06 |
| Jayzee | basically I would like to do a "bzr export ..." when stuff has been comitted to stable-branch | 12:06 |
| LarstiQ | but as alsuren said, what is it you are trying to achieve? | 12:06 |
| james_w | ah, thanks LarstiQ | 12:06 |
| LarstiQ | right | 12:06 |
| Jayzee | 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 | |
| LarstiQ | Jayzee: post_change_branch_tip sounds like the right thing then | 12:07 |
| james_w | you *could* do it from cron, but post_change_branch_tip would work nicely | 12:08 |
| Jayzee | one more thing, do I really need to write a plugin in python?? | 12:08 |
| Jayzee | I'm more confortable in php/bash | 12:08 |
| Jayzee | comfortable | 12:08 |
| james_w | I don't know what the status of the shell hooks work is | 12:09 |
| james_w | Jayzee: this plugin should not be too difficult | 12:10 |
| james_w | let me have a look for you | 12:10 |
| Jayzee | thx james | 12:10 |
| alsuren | it strikes me that having a branch type that forces the working directory to always look like the last commit would be a useful feature | 12:16 |
| james_w | alsuren: yeah, that may be something useful | 12:16 |
| james_w | I'm not sure what the best way to expose that would be | 12:16 |
| lifeless | alsuren: that implies that the working dir cannot be decoupled | 12:17 |
| lifeless | alsuren: and that it can't work efficiently over the network without a smart server | 12:17 |
| lifeless | alsuren: and that branch changes have to fail if there are local edits that conflict in the tree | 12:17 |
| lifeless | this doesn't mean its not usefl | 12:18 |
| lifeless | just the implications | 12:18 |
| alsuren | lifeless: I'll go through your points in order | 12:19 |
| Jayzee | it would be nice if bzr export would export to a already existing directory, in that way you could have the most recent using a hook | 12:19 |
| lifeless | Jayzee: thats worth filing a bug on I think | 12:20 |
| LarstiQ | Jayzee: are you per chance working locally on the machine with the www-root? | 12:20 |
| lifeless | Jayzee: btw, are you aware of the push-and-update, and also the bzr-upload plugins ? | 12:21 |
| Jayzee | yes, I have total access to it | 12:21 |
| LarstiQ | Jayzee: then the plugins lifeless mentioned shouldn't be too slow in operation | 12:22 |
| alsuren | the point is for publishing branches in a read-only form that doesn't require users' knowledge of bzr. all development would happen elsewhere | 12:22 |
| Jayzee | lifeless: I'm just started setting everything up, I come from svn-world where there's no push-update | 12:23 |
| james_w | beuno: hey, you around? | 12:24 |
| alsuren | lifeless: the second point is possibly valid, but if your project were big enough to care about performance, you would be using a smart server anyway. The time saved by being able to publish with a single push operation is massive | 12:26 |
| alsuren | lifeless: you will have to explain your third point | 12:27 |
| james_w | is there a way to get a boolean answer from a branch config? | 12:28 |
| james_w | and shouldn't hooks be passed an outf? | 12:30 |
| lifeless | alsuren: I think my first point is valid too | 12:31 |
| lifeless | alsuren: your refutation is actually talking about goals not about implementation; you proposed an implementation of 'publishing branches in a read-only form that doesn't require users' knowledge of bzr.' | 12:31 |
| james_w | Jayzee: I think this would be a useful thing to have as part of bzr-upload, and it would make the plugin much more robust. However there has to be some refactoring in that plugin first. How urgent is this for you? | 12:34 |
| alsuren | lifeless: ok, so what's the recommended implementation currently? | 12:34 |
| lifeless | bzr-upload or bzr push-and-update | 12:35 |
| Tapout | is bazaar faster than svn when it comes to really large projects? I've been running an svn commit and it's been going for about 1 hour and only 1GB done out of 4GB | 12:38 |
| alsuren | lifeless: thanks. I suspect that bzr-upload is what I'm looking for (I assume that it is possible to use bzr pull on a bzr-uploaded branch?) | 12:39 |
| alsuren | Tapout: what are you storing in your repository that makes it 4GB? | 12:40 |
| Tapout | it's a website ... docs+pdf's, text files | 12:40 |
| Tapout | svn add * ; svn commit -m "Import" | 12:40 |
| Tapout | this is on a 1Gb network, average about 35-40MB/sec between machines | 12:41 |
| james_w | alsuren: bzr-upload only uploads the tree | 12:43 |
| Jayzee | james_w: since I will be not using any distributed version control any time soon I think it's better for me to stick with svn for time being (and skip python scripts :)) | 12:43 |
| james_w | alsuren: if you bzr-upload to the same location as the branch then it should all just work | 12:43 |
| james_w | Jayzee: ah, shame. I was just wondering whether I should do a quick hack for you know, or whether you could wait a little while until we have a really elegant solution in bzr-upload | 12:44 |
| Jayzee | james_w: you can still do it properly, sooner or later I'll look at bzr again :)) | 12:45 |
| james_w | Jayzee: great, and we'll have a really nice solution for you then :-) | 12:45 |
| alsuren | james_w: ah. so it's still 2 commands if I want to use it as a public site and bzr repo at the ame time? | 12:45 |
| Jayzee | james_w: yeah, hooks are good to have :) | 12:46 |
| james_w | alsuren: yeah | 12:46 |
| james_w | alsuren: but I'm working to make it automatic right now | 12:46 |
| lifeless | alsuren: I'm not 100% sure, but beuno here is one of the authors of bzr-upload | 12:48 |
| lifeless | alsuren: I'd wager you actually want bzr push-and-update though | 12:49 |
| alsuren | lifeless: already checked, and my department doesn't have bzr installed | 12:49 |
| lifeless | alsuren: ah thats a shame. if python is on the machine you could drop it in your home dir ;) | 12:51 |
| alsuren | lifeless: tried that. installing bzr from source seems to require python-devel installed | 12:55 |
| james_w | alsuren: was that for the pyrex extensions? | 12:56 |
| alsuren | james_w: might have been... this was 3 months ago | 13:10 |
| james_w | hmm, I don't think python-devel should be required | 13:11 |
| james_w | except if there is something packaged in there that is really a runtime thing | 13:11 |
| alsuren | error: invalid Python installation: unable to open /usr/lib64/python2.5/config/Makefile (No such file or directory) | 13:12 |
| alsuren | opensuse | 13:13 |
| alsuren | when I'm in the department, I just use git instead | 13:14 |
| alsuren | james_w: if you fancy debugging, there's your info | 13:15 |
| lifeless | alsuren: we don't need the extensions - you can just do 'tar xzf bzr-1.6b4.tgz' ; bzr-1.6b4/bzr help | 13:15 |
| lifeless | alsuren: for that error, is there a 'python-dev' or similarly named package available for opensuse ? | 13:16 |
| james_w | lifeless: do you know what change is causing "Exception: Old server API in use: <bzrlib.transport.ftp.UnavailableFTPServer object at 0x978b22c>, setUp() takes exactly 1 argument (2 given)"? | 13:16 |
| lifeless | james_w: is that in a plugin ? | 13:17 |
| alsuren | yeah, but I'm not root | 13:17 |
| lifeless | alsuren: ok, well that would be whats missing for the makefile to work; but as I mention above, the C extensions are 100% optional | 13:17 |
| james_w | lifeless: yeah, I'm testing bzr-upload | 13:18 |
| lifeless | james_w: I'd annotate the constructor | 13:18 |
| alsuren | okay, so if I just put a symlink from bzr to ~/bin, it should work? | 13:18 |
| lifeless | james_w: that will give you the patch that changed the signature ;) | 13:18 |
| lifeless | alsuren: yeah. | 13:18 |
| lifeless | $ ls -l ~/bin/bzr | 13:18 |
| lifeless | lrwxrwxrwx 1 robertc robertc 43 2007-08-16 20:16 /home/robertc/bin/bzr -> /home/robertc/source/baz/bzr-test-fixes/bzr | 13:18 |
| james_w | lifeless: ok, thanks | 13:18 |
| lifeless | alsuren: all it sacrifices is some speed | 13:20 |
| alsuren | lifeless: okay, well using bzr 1.4, on the branch that I just pushed over sftp, I get bzr: ERROR: No WorkingTree exists for "file:///homes/courses/ugrad/05/dl325/swingbar/.bzr/checkout/" | 13:23 |
| lifeless | alsuren: run bzr checkout . in the swingbar directory | 13:24 |
| alsuren | lifeless: thanks (maybe that error message needs changing) | 13:26 |
| pickscrape | Are there any bugs in beta 3 that would make it inadvisable for use server-side? | 13:29 |
| alsuren | pickscrape: why don't you try it and find out (isn't that what betas are for? :P ) | 13:34 |
| === thekorn_ is now known as thekorn | ||
| james_w | ah, UnavailableFTPServer wasn't transitioned to the new API | 13:37 |
| pickscrape | alsuren: :) | 13:39 |
| ignas | what do I do with a lightweight checkout if someone deletes the branch i was bound to? | 14:00 |
| ignas | i am getting: bzr: ERROR: Not a branch: "https://code.launchpad.net/". | 14:00 |
| ignas | when trying to bind, unbind, switch, info or status | 14:00 |
| james_w | hmm, I assume switch should work | 14:01 |
| james_w | it may be a bug though | 14:01 |
| james_w | ignas: yeah, can you file a bug please? | 14:02 |
| ignas | :'( | 14:03 |
| james_w | echo -n new-location >! .bzr/branch/location | 14:04 |
| james_w | that should fix it up | 14:04 |
| james_w | -n is important | 14:04 |
| ignas | yeah, thought of doing that | 14:04 |
| james_w | I don't know if >! is a zshism though | 14:04 |
| ignas | no idea, replaced it with plain ">" | 14:06 |
| ignas | and it worked | 14:06 |
| jam | ignas: isn't there a 'bzr switch --force' ? | 14:08 |
| jam | james_w: >! *is* a zsh-ism | 14:08 |
| jam | other shells don't care if the target exists already | 14:08 |
| fullermd | Actually, >! exists in tcsh... | 14:09 |
| fullermd | (though I've never used it, since I keep noclobber unset) | 14:09 |
| ignas | jam: don't know really, i'd expect that i should get a warning that tells me to do --force it instead of an error though | 14:09 |
| james_w | --force Switch even if local commits will be lost. | 14:10 |
| james_w | it may still work, but it isn't obvious | 14:11 |
| james_w | I think there's a bug there somewhere, either that it isn't possible, or that it isn't obvious | 14:11 |
| jam | james_w: I would probably say the help should be clearer, and the switch code should be taught about not being able to open the target of the lightweight checkout and letting the user know about it | 14:13 |
| jam | certainly bugs to be fixed | 14:13 |
| ignas | why should I lose my local commits on a lightweight branch if i am switching it? | 14:14 |
| ignas | i don't think current behaviour of force is related to this kind of problem | 14:14 |
| jam | ignas: I think it *is*, it just isn't documented well | 14:22 |
| jam | The reason we require access to the old branch | 14:22 |
| jam | is to make sure nothing ends up lost | 14:22 |
| jam | but the specific help just mentions the heavy-weight checkout form | 14:22 |
| jam | where you could have local commits, and a switch will lose them | 14:22 |
| ignas | i see | 14:22 |
| jam | I'm 90% sure it is just a doc issue | 14:22 |
| ignas | just that relation between - "lost checkins" and "branch that was moved" is not completely obvious | 14:23 |
| ignas | i mean - if I would get a warning - you can't switch, we will lose your changes, because we can't access the original branch | 14:23 |
| james_w | --force doesn't work in my test here | 14:23 |
| ignas | then - yes | 14:23 |
| ignas | --force would be the thing I'd try | 14:24 |
| ignas | but not with the "old branch does not exist!" error | 14:24 |
| lifeless | ignas: lose local commits? lightweight brnaches don't have local commits.. | 14:34 |
| ignas | lifeless: precisely, so even if "switch --force" would fix missing remote branch problem, with --force being described as "switch even if local commits will be lost" I would not have any way of finding out that it is the option I need | 14:36 |
| ignas | and even without local commits, you still can lose local changes | 14:37 |
| ignas | if i have changed some file, and the remote branch disappeared, bzr won't be able to find out which files I have modified, unless you do some magic that I am not aware of | 14:38 |
| lifeless | ignas: what changes have you list ? | 14:40 |
| ignas | ? | 14:40 |
| pickscrape | lost? | 14:40 |
| ignas | ahh, well - my lightweight checkout was not modified | 14:41 |
| ignas | I think | 14:41 |
| ignas | ok | 14:41 |
| ignas | it was modified | 14:41 |
| ignas | but switching the location | 14:41 |
| ignas | did not lose anything | 14:41 |
| ignas | so yeah, you are doing some tracking somewhere | 14:42 |
| lifeless | ignas: :) gotta be careful of these assertions :) | 14:45 |
| ignas | i kind of assumed that if you are losing local checkins, chances of keeping local changes in place without the parent branch being present are pretty low | 14:46 |
| ignas | still - having an interface to fix --ligthweight checkouts would be kind of nice | 14:47 |
| lifeless | whats broken ? | 14:52 |
| ignas | make a lightweight checkout, remove the original branch (or move it) try bzr st,info, switch, bind, unbind ... | 14:53 |
| ignas | i had to edit .bzr/branches/location to fix it | 14:54 |
| lifeless | hmm yes | 14:54 |
| lifeless | please make sure there is a bug open for this | 14:54 |
| lifeless | if it fails on 1.6b4 | 14:54 |
| ignas | could someone with 1.6b4 check it, because I don't really have a bzr checkout around ... | 14:56 |
| ignas | only bzr that is available in ubuntu (ppa one) | 14:57 |
| ignas | 1.6b3 | 14:57 |
| ignas | i can repro it on 1.6b3 | 14:59 |
| ignas | https://bugs.launchpad.net/bzr/+bug/198821 is there already | 15:02 |
| ubottu | Launchpad bug 198821 in bzr "switch of lw checkout shouldn't require force when branch moved" [Medium,Confirmed] | 15:02 |
| === mw|out is now known as mw | ||
| ahasenack | Hi, I'm using bzr 1.3.1 on a client and branching from a server that is running 1.6b3, and I get this warning on the client: "Server is too old for streaming pull, reconnecting. (Upgrade the server to Bazaar 1.2 to avoid this)" | 15:11 |
| james_w | ahasenack: hi | 15:13 |
| ahasenack | james_w: hi | 15:13 |
| james_w | the problem is that the verb was removed, and the code just assumes that means that it is too old, but in this case it is too new | 15:14 |
| james_w | there is a bug open, but I believe it's marked "Won't Fix" | 15:14 |
| james_w | the message is misleading, but everything still works | 15:14 |
| ahasenack | ok | 15:14 |
| spiv | If you update the client to 1.6b3 you won't see that message. That's a fix ;) | 15:15 |
| ignas | what is the rationale behind showing this to users a.k.a. clients, it's like firefox telling me that some server is using an old version of apache :/ | 15:16 |
| spiv | The reason is that when client and server versions are mismatched things can sometimes be surprisingly slow | 15:16 |
| spiv | Because the protocol is still in flux, so while things will still work, the mismatched versions might not be able to figure out how to do it quickly. | 15:17 |
| james_w | yeah, I guess it's like the discussion over when to show an upgrade message for formats | 15:17 |
| spiv | So by telling the user that there is a mismatch like that it lets them know how to fix bad performance. | 15:18 |
| ignas | my point is - I can't access most servers, much less upgrade software on them | 15:19 |
| spiv | That's the logic, anyway. Ideally there would be some way to suppress those warnings if you're sure you don't care about them, but no-one has cared enough to volunteer a working patch ;) | 15:19 |
| ignas | so the benefit of the warning is like - firefox telling me that "this site is slow, because they misconfigured caching, it's not our fault" | 15:20 |
| spiv | Pretty much. "We know this is sucking, here's why, now you know who to talk to to get it fixed." | 15:21 |
| spiv | We are erring on the side of verbosity here. | 15:21 |
| spiv | I think it'd be fine to have e.g. a locations.conf setting to suppress that warning, so you could choose not to be informed about it for particular sites. | 15:23 |
| spiv | The long term fix is to stop changing the protocol so much :/ | 15:23 |
| alsuren | also, there's something to be said for encouraging everyone to keep their softare up-to-date. Especially with a project that's moving as fast as bzr | 15:23 |
| ignas | well - if you are assuming that most of bzr users can do something about servers they are using .... | 15:23 |
| ignas | then showing warning by default makes sense | 15:23 |
| alex-weej | hello | 15:24 |
| alex-weej | when i commit to my local repo i'd like for it to be mirrored instantly online when possible | 15:24 |
| alex-weej | is it "bind" that i need? | 15:25 |
| alex-weej | i'm using lp btw | 15:25 |
| ignas | yes | 15:25 |
| spiv | Many can, especially if you count "email the sysadmins of the server" as doing something about it ;) | 15:25 |
| spiv | I don't much like that it makes it feel like bzr is nagging you, especially because you might not be able to do something about it, at least not immediately. But I'd rather give more information about what is going on rather than less. | 15:26 |
| alex-weej | so how do i tell bind to use the default push location? | 15:27 |
| ignas | bzr info | 15:27 |
| ignas | copy the url | 15:27 |
| ignas | and do bzr bind url | 15:27 |
| spiv | Anyway, it's time to sleep. | 15:27 |
| jam | beuno: ping | 15:31 |
| jam | spiv: sleep well spiv | 15:31 |
| spiv | jam: thanks :) | 15:32 |
| * spiv -> really sleep! | 15:32 | |
| beuno | jam, pong | 15:33 |
| jam | beuno: I'm happy to see the new theme land on Launchpad, but at least here, the annotate view has far too much whitespace | 15:33 |
| * beuno looks | 15:34 | |
| jam | I don't know if this is LP specific, or if it is part of the latest trunk | 15:35 |
| jam | But certainly something is a bit off with the CSS | 15:36 |
| wingo-tp | lifeless: cough poke #239499 :) | 15:36 |
| beuno | it's the same for both | 15:36 |
| beuno | it's the same for both | 15:36 |
| beuno | so fixing trunk should fix LP | 15:36 |
| * beuno files bug | 15:36 | |
| jam | bug #239499 | 15:36 |
| ubottu | Launchpad bug 239499 in bzr "corrupt knit index on an old arch-imported bzr repo" [Medium,Confirmed] https://launchpad.net/bugs/239499 | 15:36 |
| beuno | jam, does the line spacing in diffs seem fine to replicate in annotate? | 15:40 |
| jam | beuno: checking now | 15:41 |
| beuno | jam, http://bazaar.launchpad.net/%7Eloggerhead-team/loggerhead/trunk/revision/190 | 15:41 |
| beuno | (LH in LP seems very slow today) | 15:42 |
| jam | beuno: it is a lot better, but compare it to: http://bzr.arbash-meinel.com/gvim_spacing.png | 15:43 |
| jam | That is the spacing in my text editor | 15:43 |
| jam | You can make the text bigger if you give less whitespace | 15:43 |
| jam | Anyway, if I had to chose between current, and diff view, I'd pick diff view | 15:44 |
| jam | But *I* would probably go further | 15:44 |
| jam | *I* am not a web designer or graphics designer, and my fashion sense is poor, though | 15:44 |
| beuno | sure, I'd prefer to fix everything at once | 15:44 |
| beuno | I'll make the bug about spacing in general | 15:44 |
| jam | I would guess the spacing in T-bird is about the same as gvim | 15:44 |
| beuno | and see if it looks too ugly :) | 15:44 |
| beuno | jam, bug #253981 | 15:47 |
| ubottu | Launchpad bug 253981 in loggerhead "Line spacing for code text is too big" [Medium,Confirmed] https://launchpad.net/bugs/253981 | 15:47 |
| jam | joy.... the other day they reset LP passwords, and now I'm on Linux so I have to log in | 15:49 |
| jam | Then I log in to the normal site | 15:49 |
| jam | which redirects me to edge | 15:49 |
| jam | and I'm not logged in again | 15:50 |
| james_w | beuno: hey lp:~james-w/bzr-upload/auto_upload | 16:01 |
| james_w | what do you think about including that? | 16:02 |
| * beuno branches | 16:04 | |
| james_w | it don't work if you commit from a checkout in the same shared repo as the branch with the configuration, but it looks like that may be a bzr bug | 16:04 |
| beuno | james_w, I really like the idea. How would you specify which branch you want to be auto-uploaded? | 16:08 |
| james_w | auto_upload = True | 16:08 |
| james_w | in wherever you put upload_location | 16:09 |
| beuno | ah, right, I missed that | 16:09 |
| james_w | upload_automatically may be better as it has "upload" first, but it's a pain to spell | 16:09 |
| beuno | it would be cool to be able to set it from the command like, but the branch looks very good as-is | 16:09 |
| james_w | yeah, sorry, didn't add any docs yet | 16:09 |
| james_w | bzr upload --auto? | 16:10 |
| beuno | yeah, that sounds good | 16:10 |
| beuno | and --noauto? | 16:10 |
| james_w | good idea | 16:10 |
| james_w | I need to work out how to test it as well | 16:10 |
| beuno | and, vila will kill me if I add anything without tests | 16:10 |
| beuno | that's it :) | 16:10 |
| beuno | I have some LH work today, but I'll try and help you out with this so we can merge | 16:11 |
| beuno | it looks very good, so thanks :) | 16:11 |
| james_w | I should finish my TreeTransform patch first though | 16:11 |
| james_w | you don't mind adding the class in __init__.py | 16:11 |
| james_w | I couldn't run the command from the hook, as the source branch is already write locked. | 16:12 |
| beuno | not at all, it moves logic out of the command | 16:13 |
| beuno | or we could move logic out of the command, actually :p | 16:13 |
| beuno | james_w, anyway, just a little bit of work on top of that, and it's perfect | 16:14 |
| james_w | beuno: can you try it from inside a shared repo? | 16:15 |
| james_w | i.e. create a shared repo with a branch in, upload that somewhere, then add the auto_upload = True | 16:16 |
| beuno | james_w, yeap, just need to pack up and move to the office for a few hours, so I will in a bit | 16:16 |
| james_w | then checkout in the same shared repository, and commit from there | 16:16 |
| james_w | beuno: sure, no problem, just wanted to rule out a screw up on my end | 16:16 |
| beuno | james_w, I have a use case for this at work, so I'll plug this right in so we can test it a bit. It even uses a shared repo already | 16:17 |
| james_w | beuno: great, I love it when a solution finds a problem | 16:19 |
| jam | james_w: why not just "upload_auto = True" | 16:23 |
| james_w | that would work I guess, it just feels ungrammatical | 16:23 |
| james_w | it's not a novel though | 16:23 |
| jam | upload_automatically_for_thou_art_my_biznatch = True | 16:39 |
| jam | I don't think I would read that book, though | 16:39 |
| robtaylor | lifeless: just read your partial commits idea, sounds lovely! | 16:41 |
| thekorn | hi all, | 17:15 |
| thekorn | I have once again a bzrlib question, | 17:16 |
| james_w | hey thekorn | 17:16 |
| thekorn | let's say I know the path to a versioned file | 17:16 |
| thekorn | hi james_w | 17:16 |
| thekorn | how can I get the revno of this file? | 17:17 |
| thekorn | similar to bzr revno /boo/bar/baz.py | 17:17 |
| james_w | I'm not sure whether "bzr revno /boo/bar/baz.py" does what you think, let me check | 17:20 |
| james_w | yeah, that just prints the revno of the last revision on the branch containing that file | 17:21 |
| james_w | you want to know the revno of the last revision that changed that file? | 17:21 |
| thekorn | james_w, no just the current revision of this the branch which contains this file | 17:22 |
| thekorn | james_w, sorry I just found it in buildins.py | 17:22 |
| james_w | cool | 17:22 |
| thekorn | it is BzrDir.open_containing(location)[0].revno() | 17:23 |
| thekorn | that was easy :) | 17:23 |
| thekorn | actually not BzrDir but bzrlib.branch.Branch, but it works | 17:25 |
| james_w | beuno: hey, are you settled in the office yet? I'd like some testing advice. | 17:35 |
| jelmer | any dd around that can upload a new version of trac-bzr for me? | 17:55 |
| beuno | james_w, yeap | 17:57 |
| james_w | beuno: it looks like the uploading is well covered by tests, so we just want to make sure that an upload is triggered by a commit | 17:58 |
| beuno | correct | 17:58 |
| james_w | You've got an interesting test strategy though, so I'm not sure of the best way to integrate with it | 17:58 |
| beuno | right, it's less flexible then I'd like | 17:59 |
| beuno | it seems like you have to duplicate a lot of code, right? | 17:59 |
| james_w | yeah, that's what I was worried about | 18:00 |
| james_w | it seems like I could have something completely separate fairly easily, but that might be too much duplication | 18:00 |
| james_w | you wouldn't want this to be tested against different transports and things though, would you? | 18:01 |
| Nyad | hi. I'm reading the bazaar in 5min guide, I'm trying to push to a branch on launchpad.net so $ bzr push bzr+ssh://joseph.werd@bazaar.launchpad.net/~vorkasm-project/vorkasm/vorkasm-v1.0.4 | 18:03 |
| Nyad | but it's not working | 18:04 |
| james_w | hi Nyad | 18:04 |
| james_w | do you get an error? | 18:04 |
| beuno | james_w, no, I think we can safely assume that if it works with one, it works with all. We just want to test it auto-commits | 18:04 |
| Nyad | james_w: bzr: ERROR: Not a branch: "/home/jason/". | 18:05 |
| james_w | sure, I'll put something together | 18:05 |
| james_w | Nyad: are you in "/home/jason/" when you run the command? | 18:06 |
| beuno | Nyad, you have to push from the dir that has the branch | 18:06 |
| Nyad | oh, woops | 18:07 |
| Nyad | n | 18:09 |
| Nyad | The authenticity of host 'bazaar.launchpad.net (91.189.94.254)' can't be established. I have created an ssh key pair | 18:09 |
| james_w | Nyad: if you "ssh bazaar.launchpad.net" you will get a chance to verify the key | 18:10 |
| rocky | i gotta say i'm not really sure the point of doing an init-repo when if i merely do a checkout or branch it doesn't need it | 18:10 |
| luks | rocky: speed and disk space are two reasons for doing it | 18:11 |
| asabil | rocky: init-repo is an optimization for making branching faster | 18:11 |
| Nyad | james_w: I got the same error when I ran that | 18:11 |
| james_w | Nyad: it doesn't let you accept the key? | 18:11 |
| rocky | oh ok | 18:11 |
| luks | rocky: without the shared repository, it has to copy all the data | 18:12 |
| james_w | rocky: if you only ever have one branch then it's no win, but once you have more than one it is | 18:12 |
| asabil | rocky: let's say that you have a branch "A", that has 3 revisions (1, 2, 3) | 18:12 |
| luks | rocky: but if you branch in a shared repository, nothing is copied | 18:12 |
| james_w | rocky: and if there's any chance of having more than one then I suggest you create one, it will save you effort later | 18:12 |
| asabil | rocky: if you create branch "B" from "A", outside of a repo, then you will copy all the 3 revisions | 18:12 |
| Nyad | james_w: it says "Are you sure you want to continue connecting (yes/no)? " | 18:12 |
| asabil | rocky: if "A" was in a repo, then the revisions were actually stored in the repo, and "A" only contained "pointers" to them | 18:13 |
| james_w | Nyad: ah, you can then say "yes", and it will let you connect from now on | 18:13 |
| asabil | so creating a branch "B" would be just a matter of pointing to the same revisions, instead of copying them | 18:13 |
| === davi__ is now known as davi_ | ||
| grahal | for testing, i was tried to make my Documents directory into a bazaar repo | 18:24 |
| grahal | it's about 600mb in size | 18:24 |
| grahal | lot's o binaries as you may expect | 18:24 |
| Nyad | james_w: ok that works, thanks | 18:24 |
| grahal | when I ran "bzr add .", bzr ran for a while and I noticed it started eating up memory | 18:25 |
| grahal | continuous scaling, 60% in a 1GB machine | 18:25 |
| grahal | and growing | 18:25 |
| grahal | is that expected? is the use case not supported at all? | 18:25 |
| korpios | AFAIK bzr's optimized for source code much moreso than binary data | 18:25 |
| korpios | I wouldn't say that use case is ignored, just that it's definitely not ideal right now | 18:26 |
| grahal | it's a curious use case, at least to consider any sort of design decision when dealing with "add" operation | 18:27 |
| grahal | certainly not top priority I believe | 18:27 |
| korpios | for binary data, a more basic backup system is probably better (e.g., Apple's Time Machine) | 18:29 |
| grahal | yeah... this test idea came to mind mind because I read some time ago the idea to do something a like apple's time machine in ubuntu | 18:30 |
| grahal | and bzr was being considered as the backend | 18:30 |
| grahal | google summer of code stuff | 18:30 |
| grahal | not sure what happened with such idea | 18:30 |
| james_w | hmm, maybe hooks aren't run in test code | 18:33 |
| beuno | james_w, maybe you can steal code from lifeless' bzr-search | 18:33 |
| beuno | he uses hooks and has tests | 18:33 |
| james_w | ah, nice, I was trying to think of a plugin with tests | 18:33 |
| james_w | er, I mean hooks :-) | 18:33 |
| james_w | thanks | 18:33 |
| beuno | :) | 18:35 |
| james_w | but it doesn't test the hooks it seems | 18:37 |
| beuno | ah, bad lifeless! | 18:37 |
| james_w | aha, bzr-dbus to the rescue | 18:40 |
| jam | grahal: was this during "bzr add" or "bzr commit" | 18:40 |
| jam | If it was during "bzr add" that would be *quite* unexpected | 18:40 |
| jam | commit wouldn't be as surprising | 18:40 |
| grahal | sorry | 18:40 |
| grahal | during commit | 18:40 |
| grahal | you are right | 18:41 |
| jam | so... our specific goal is to hold < 3 copies of any text in memory at a given time | 18:41 |
| jam | (merge needs 3 copies to compare against) | 18:41 |
| jam | I have the feeling we are missing something trivial in commit | 18:41 |
| jam | which is causing us to hang on to old texts that we aren't using anymore | 18:41 |
| jam | but I haven't personally spent the time profiling it, etc. | 18:42 |
| jam | (It is hard to profile memory consumption in python) | 18:42 |
| james_w | beuno: so, they are disabled, which makes sense. I can add a check that the hook is registered, and then tests triggering it manually, would that satisfy you? | 18:43 |
| === davi_ is now known as davi | ||
| beuno | james_w, yeah, absolutely | 18:45 |
| beuno | we can also add a message notifying the user it's auto-uploading | 18:45 |
| beuno | or spit it out to ~/.bzr.log | 18:46 |
| james_w | yup | 18:46 |
| beuno | just so we know when it's auto-uploading | 18:46 |
| james_w | and thankyou again for your contributions to loggerhead, I'm using it now and it's so much better | 18:48 |
| beuno | james_w, I've really been enjoying it, so my pleasure :) | 18:50 |
| gerel | hey, can i maintain a working-tree on the main branch server such that it's updated when I commit/push to it ? | 18:56 |
| beuno | gerel, push-and-update if you want bzr data | 18:57 |
| beuno | and bzr-upload if you just want the working tree | 18:57 |
| gerel | hmm | 18:57 |
| gerel | i'll ty | 18:57 |
| gerel | try | 18:57 |
| beuno | and if you want for bzr-upload to upload automatically on commit, wait for a while for james_w's patch to land :) | 18:58 |
| james_w | beuno: it's working :-) | 18:58 |
| gerel | beuno: when you say push-and-update you mean, bzr push, bzr update from my local working-tree ? | 18:58 |
| james_w | just got to finish the tests and add --auto | 18:58 |
| beuno | gerel, no, it's a plugin | 18:58 |
| gerel | agggh | 18:59 |
| beuno | james_w, rockin' | 18:59 |
| gerel | beuno: it's weird since i tested it and when the repo is on my local disk it actually copies the working-tree | 18:59 |
| gerel | beuno: but when the repo is remote, it doesn't | 18:59 |
| beuno | gerel, right, locally, it auto-updates | 18:59 |
| beuno | remotely, it doesn't | 19:00 |
| gerel | pty | 19:00 |
| beuno | that's the intended behaviour | 19:00 |
| gerel | pity | 19:00 |
| beuno | you can't guarantee remote updates, since you need bzr on the other side | 19:00 |
| beuno | se we have plugins that work around it | 19:00 |
| beuno | what's the problem with using a plugin? | 19:00 |
| gerel | ah, nothing, but im kinda tired doing apt-get :-P | 19:01 |
| beuno | gerel, well, it isn't packaged, so you don't have to worry about that | 19:01 |
| * beuno ducks | 19:01 | |
| gerel | beuno: the other workaroun is issuing a checkout on the remote host | 19:01 |
| gerel | beuno: hah forget it | 19:02 |
| beuno | gerel, bzr co lp:bzr-push-and-update ~/.bazaar/plugins/pushandupdate | 19:02 |
| beuno | should have it running in a minute | 19:02 |
| gerel | nice | 19:02 |
| gerel | beuno: in short, the --no-trees is useful only when doing local repos | 19:04 |
| beuno | gerel, right | 19:04 |
| evarlast | hello, I'm getting a LockFileEx error on win32 trying to branch from a network mapped drive. | 19:04 |
| gerel | beuno: otherwise it's automatically used | 19:04 |
| beuno | evarlast, can you pastebin the full error? | 19:04 |
| beuno | !pastebin | 19:05 |
| ubottu | pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic) | 19:05 |
| jam | lifeless: when you wake up, can you check the PQM logs? I seem to have some patches that pass the test suite, but then "die". I don't get a success or failure message, and I don't see a commit going to the bazaar-commits mailing list | 19:24 |
| jam | I checked to see that the tests really were running | 19:24 |
| jam | and when I submitted one with an error, I got a failure right away | 19:25 |
| jam | it seems something bad is happening after "make check" succeeds | 19:25 |
| jam | Odd_Bloke: ^^ You *might* want to see if there is something to be fixed here. But you'll probably want to wait for a better bug report | 19:25 |
| Odd_Bloke | jam: poolie was having issues as well. | 19:29 |
| Odd_Bloke | But, yeah, I'll wait for a better bug report if one is needed. | 19:29 |
| jam | james_w: You need to send your email to the list, I didn't CC so you didn't look as foolish :) | 19:42 |
| james_w | jam: well it's twice as bad now :-) | 19:43 |
| === abadger19991 is now known as abadger1999 | ||
| james_w | beuno: lp:~james-w/bzr-upload/auto_upload/ should be more to your liking | 19:58 |
| * beuno pulls | 20:00 | |
| beuno | james_w, you rock, merging now | 20:04 |
| james_w | cool, thanks | 20:04 |
| james_w | beuno: I'm gonna spend some time selling bzr and bzr-upload to my web developer friend soon, I think she's going to love it. It does make a pretty easy and interesting way of deploying code. | 20:06 |
| james_w | I'll make sure to pass on any suggestions that she has | 20:06 |
| beuno | james_w, yay! more users. Any feedback will be very welcome | 20:07 |
| james_w | and she's got a friend who does presentations and training on how to do this with svn, so hopefully I can get her to switch as well | 20:08 |
| jam | james_w: Is there no feature that can tell if hardlinks are supported? | 20:12 |
| jam | Or does the "create_hardlink" just fall back to create_file if it can't create a hard link? | 20:13 |
| james_w | jam: oh yeah, I thought about that as I was writing the test, but forgot to revisit it | 20:13 |
| james_w | but yes, there is a feature | 20:14 |
| james_w | I'd fix it, but I'm just heading out the door | 20:14 |
| ahasenack | guys, https://launchpad.net/~bzr/+archive is missing hardy 1.5.0 packages | 20:14 |
| james_w | any other review comments that I could fold in would be appreciated | 20:14 |
| ahasenack | for bzr (bzrtools is there) | 20:14 |
| james_w | hey ahasenack | 20:14 |
| james_w | I heard tell they were removed | 20:15 |
| jam | james_w: "If self.tree_kind(trans_id) != self.final_kind(trans_id)" is that true when the target is being deleted? | 20:15 |
| jam | Or does that just raise "NoSuchFile" ? | 20:15 |
| ahasenack | I know 1.6b3 was removed from there | 20:15 |
| ahasenack | hmm | 20:15 |
| james_w | that will be it then, poolie should probably re-upload 1.5 with a "really" version number | 20:15 |
| jam | I'm also a *little* concerned about raising + catching an exception in an inner loop when there maybe 1000s of content changes due to a merge | 20:15 |
| ahasenack | the hardy one is in state "superseeded" | 20:15 |
| ahasenack | bzr - 1.5.0-1~bazaar1~hardy1 beuno 2008-05-17 Superseded Hardy | 20:16 |
| james_w | jam: yeah, I tried to minimise the number of times it would be called, but it's not ideal | 20:16 |
| ahasenack | probably because 1.6b3 was uploaded for hardy, then removed but 1.5.0 was not reuploaded | 20:16 |
| ahasenack | ok | 20:16 |
| james_w | jam: I don't know if I could avoid the exception | 20:16 |
| jam | james_w: well, this is "_apply_removals" right? | 20:17 |
| jam | So things which are actually deleted will raise the exception | 20:17 |
| james_w | jam: but yes, I think that raises NoSuchFile, and we're not building up and exact list of kind changes, just collecting all the ones we can to make sure they get an inventory_delta entry | 20:17 |
| james_w | yeah, it's _apply_removals | 20:18 |
| jam | james_w: well, it seems abentley asked for this | 20:18 |
| jam | but to be honest | 20:18 |
| jam | it doesn't seem to fit the way everything else is tracked | 20:18 |
| jam | specifically, apply_insertions | 20:18 |
| jam | does a lot of | 20:18 |
| jam | "if trans_id in self.XXX" | 20:18 |
| jam | and now we are creating a separate local variable | 20:18 |
| james_w | yeah | 20:19 |
| james_w | I think actual removals go through a different code path, only modifications hit this one | 20:19 |
| james_w | I think I understood the other approach more, I'd like to know abentley's reasoning | 20:20 |
| james_w | my guess was keeping state is more likely to be buggy | 20:20 |
| jam | james_w: well, his claim was that the information is already somewhere | 20:20 |
| jam | so it would lead to redundancies | 20:20 |
| abentley | james_w: I thought I explained. It's redundant with other data we have. | 20:20 |
| jam | but where is it storeed | 20:20 |
| jam | ? | 20:20 |
| james_w | hi abentley | 20:21 |
| abentley | jam: TT._new_contents | 20:21 |
| jam | abentley: so is it just as simple as: | 20:21 |
| jam | or trans_id in self._new_contents ? | 20:21 |
| jam | adding that to the "apply_insertions" if statement? | 20:21 |
| abentley | jam: Well, you could. That's a bit overkill. | 20:22 |
| jam | abentley: then it doesn't sound redundant to have a *smaller* list | 20:22 |
| abentley | jam: I would suggest comparing to the tree kind. | 20:22 |
| jam | list / set | 20:22 |
| abentley | jam: we already know the state in the old tree. We already know what files are getting new contents. | 20:23 |
| jam | abentley: do we know what files are becoming directories? | 20:23 |
| jam | aka, losing content | 20:23 |
| jam | and getting a new kind | 20:23 |
| abentley | jam: yes. | 20:23 |
| jam | as that was the bug here | 20:23 |
| jam | that it wasn't actually creating an inventory entry for it | 20:23 |
| jam | an inventory *delta* entry | 20:23 |
| abentley | jam: _new_contents lists all files, symlinks and directories that are getting new contents on disk. | 20:24 |
| jam | abentley: but the idea is that you don't need an inventory entry just for a content update? | 20:25 |
| jam | Since you pass it the full Inventory Entry, I would have thought that you would | 20:25 |
| jam | (since the sha1sum / size / etc are changing) | 20:25 |
| jam | And it *might* be a solution for the "commit doesn't update sha1sum" bug we are having | 20:25 |
| jam | (I could certainly be conflating things, though) | 20:26 |
| abentley | jam: This is working tree state that's being updated, so the sha1sum and size are not expected to be accurate. | 20:26 |
| abentley | gotta eat. | 20:29 |
| rocky | jelmer: i'm seeing extreme slowness when committing to a svn checkout using bzr-svn ... is that normal? | 20:29 |
| jelmer | rocky, hi | 20:29 |
| james_w | right, I'm off, I'll work on this on Monday probably, so any review comments will be appreciated. | 20:29 |
| jelmer | rocky, first time may be a bit slow | 20:29 |
| rocky | oh ok | 20:29 |
| evarlast | http://paste.ubuntu.com/33097/ | 20:37 |
| evarlast | LockFileEx not supported in vista client and XP server with server being a USB device shared. | 20:38 |
| jam | evarlast: sounds like you are running into a problem with accessing the working tree when doing 'bzr branch' | 20:38 |
| jam | Unfortunately the new code path tries to copy file contents from a WT if it can find one | 20:38 |
| jam | because it is often faster than reading it out of the repo | 20:38 |
| jam | and we didn't add a way to say "just branch and ignore the WT" | 20:38 |
| jam | abentley: ^^ Thoughts? | 20:38 |
| jam | (abentley is currently eating, but he is the one that implemented the WT processing) | 20:39 |
| jam | evarlast: if you are just looking to "get going" you can do this trivial hack | 20:39 |
| jam | cd other | 20:39 |
| jam | mv .bzr/checkout .bzr/checkout-hidden | 20:39 |
| jam | evarlast: then 'bzr branch' will work | 20:39 |
| jam | and you can "mv .bzr/checkout-hidden .bzr/checkout" later. | 20:39 |
| evarlast | really? | 20:41 |
| evarlast | i'll try that, thanks. | 20:42 |
| jam | evarlast: we only use LockFileEx on working trees | 20:42 |
| evarlast | ah, and this fakes being a non-working tree. | 20:43 |
| evarlast | very cool. thanks. | 20:43 |
| n[ate]vw | Quick ?: bzr status on both my laptop and desktop show no uncommited changes. Is there a way, though, to check which revision both are on? | 20:51 |
| beuno | n[ate]vw, bzr revno | 20:52 |
| jam | n[ate]vw: 'bzr missing' between them | 20:52 |
| jam | bzr log -r -1 | 20:52 |
| jam | bzr revision-info | 20:52 |
| jam | bzr revno | 20:52 |
| jam | n[ate]vw: need any more? :) | 20:52 |
| n[ate]vw | awesome, revno was exactly the info I didn't know how to get | 20:52 |
| n[ate]vw | missing looks handy too, but takes almost as long as a pull so not sure how much I'll use it | 20:53 |
| n[ate]vw | thanks! | 20:53 |
| jam | n[ate]vw: what version of bzr? | 21:04 |
| jam | n[ate]vw: (just to mention that 'bzr missing' is much faster in 1.6) | 21:05 |
| n[ate]vw | 1.3.1 | 21:05 |
| jam | well, soon-to-be-released 1.6 :) | 21:05 |
| n[ate]vw | jam: I should upgrade, I'm sure there's other good stuff too | 21:05 |
| jam | so you may want to revisit it | 21:05 |
| n[ate]vw | shelve is still a separate plugin, though, right? | 21:06 |
| jam | n[ate]vw: shelve is in 'bzrtools' | 21:09 |
| jam | mostly because it relies on "patch" being an available program | 21:09 |
| jam | and it fails for non-text files | 21:10 |
| n[ate]vw | ah, ok | 21:10 |
| n[ate]vw | keep realizing I haven't gotten around to installing it on the occasional occasions I need it | 21:10 |
| Demosthenes | with my rcs files i used the header keywords to put the RCS version # in my file header, does BZR have a similar feature? | 21:19 |
| Peng_ | Demosthenes: It's in progress. http://bazaar-vcs.org/KeywordExpansion | 21:30 |
| jam | Demosthenes: though it may not be what you really want: http://jam-bazaar.blogspot.com/2008/07/last-week-in-bazaar.html | 21:33 |
| pickscrape | Could anyone point me at a decent example of how to add a pre-commit hook? | 22:24 |
| pickscrape | I found one but it used a method that was apparently deprecated in 1.5 | 22:24 |
| jam | pickscrape: what was the deprecated function? (I'm guessing install_hook versus install_named_hook) | 22:42 |
| pickscrape | jam: yes, thanks. I found that myself by looking at the release notes | 22:43 |
| jam | that should be the only *major* difference, which just means passing in a name at the same time | 22:43 |
| jam | rather than installing it | 22:43 |
| jam | and then naming it as 2 separate steps | 22:43 |
| pickscrape | I think I have everything I need now: just need to read up on TreeDelta and RevisionTree which I haven't needed to touch so far :) | 22:44 |
| lifeless | hi jam will you be wowing ? | 22:57 |
| lifeless | jam: ^ | 23:04 |
| jam | lifeless: probably not, family time tonight | 23:37 |
| lifeless | jam: kk enjoy | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
