[00:02] lifeless: did you revert the bug policy change? [00:11] yes [00:11] about 5am or so [00:14] its now blocked on you, aaron's approve vote notwithstanding [00:17] i can't go for "use either one randomly" [00:18] i could be convinced to use it as Ubuntu does, meaning that random users can't "really" confirm it [00:18] but that feels more heaviweight than necessary [00:18] especially if you think about bugs flipping incomplete/confirmed [00:18] "somebody does it" or even "lots of people do it" is not very convincing [00:19] lots of people use 8-space tabs but i don't want random bzrlib files being done with 8-space tabs [00:21] mm [00:21] poolie: so, I don't think I was asking for random; only to not have to memorise different rules when the difference doesn't gain us anything. [00:21] if you can point to something we gain by being consistent, I'll jump on board and be as consistent as a consistent thing [00:21] the rule being "don't use triaged"? [00:23] a rule we haven't been honouring for some time, based on bug database evidence [00:23] sheesh [00:23] morning [00:23] if it hasn't been causing harm, I think we should relax the rule [00:23] hi poolie, lifeless, jam [00:24] hi igc [00:24] also, according to bug database evidence, we have lots of bugs, therefore we should keep having them? [00:24] be serious [00:24] hi igc [00:25] sheese yourself, totally useless analogy - not the same thing at all. [00:25] * lifeless goes back to fixing bug 393677 [00:26] Launchpad bug 393677 in bzr "pushing a 1.9 branch stacked on a 2a branch causes problems" [High,Confirmed] https://launchpad.net/bugs/393677 [00:55] poolie: sorry we got cut off. my cell phone died and I had to pick up my son anyway. If you want to chat more, maybe we can do so after a couple hours [01:25] np [01:25] jam, ping me here if you like [01:26] Hi igc. [01:26] hi garyvdm! [01:26] I've been working on a blue print for a text conflict resolving tool. [01:27] It's not finished yet, but there lots done so far. [01:27] http://bazaar-vcs.org/qbzr/Blueprint/diffmerge [01:28] ooh [01:28] Just wanted to bring you attention to it. I would like to discusses it in detail post 2.0 [01:28] And with vila [01:28] Hi poolie [01:29] igc: The bits I still need to spec out is the intergration with annotate and log. [01:30] automatically helping you find the context for the merge would be excelletn [01:30] igc: Hey, quick fast-import Q... does it rely on essentially holding the stream in memory? [01:31] fullermd: no [01:31] little bits of [01:31] memory issues? [01:31] fullermd: no [01:31] Good night all. [01:32] So, if I've got this ~3.5 gig SVN repo, it probably won't want to suck up memory on that order to import? [01:32] fullermd: heh [01:32] no [01:32] ports? [01:32] fullermd: that's a baby :-) [01:32] No, ports is still in CVS. src is in SVN. [01:33] I still don't have the guts to tackle ports :p [01:33] \o/ [01:33] fullermd: the emacs fastimport dump is 7.5GB gzipped [01:33] fullermd: does it have modules at all? [01:34] It _is_ a module ;) [01:35] fullermd: the main thing to watch is that svn-fast-export.py falls over on huge repositories (like OOo) with "too many open files" [01:35] fullermd: that's a bug somewhere is the python-subversion bindings I think [01:36] Funny, I was thinking that the other week when I glanced at what was needed for it... [01:36] fullermd: but it often works (and there's a svn-fast-export.c that doesn't have the issue if it does) [01:36] "Subversion python bindings? You mean the ones that jelmer gave up on using 'cuz they were too buggy?" [01:37] fullermd: there's at least 3 binding to my knowledge, so probably but not sure [01:37] bindings [01:37] python-subversion [01:37] subvertpy [01:37] and pysubversion [01:37] IIRC [01:38] So much simpler with CVS, where everybody gets to just implement their own RCS file parser... [01:47] abentley: I've been using your pipeline plugin since yesterday and I love it. Thanks a lot! :) [01:54] igc, i thought you wrote some developer docs about content filtering but i don't see them in the tree [01:54] did they get lost, or was it perhaps just a mail thread that i was thinking of? [01:55] abentley: poolie has asked that I land the iter changes branch and we tweak from there - even if that is to then put the UI back the way it is now. [01:55] abentley: just giving you a heads up === Noldorin_ is now known as Noldorin [02:00] jkakar: Cool! [02:02] abentley: I have a pipeline with 8 branches and am happily making progress jumping between them. [02:03] lifeless, poolie: I don't want to get it the way of fixing bugs. But it feels like fixing the bug has gotten married to UI changes whose value is not clear-cut, and could easily have been done separately. [02:04] jkakar: Wow, that might be the deepest bzr pipeline ever. :-) [02:05] abentley: Heh. :) [02:05] abentley: I'm refactoring a bunch of existing code that has a nice hierarchy of objects already implemented. [02:06] abentley: I'm using a pipe for each level, making the changes I want, and slowly working my way through it. Having pipes is actually helping me focus and figure out clean ways to make the changes I want to make. [02:07] jkakar: I find it helps that way too. Sometimes I'll work on something as a pipeline, even when I wind up submitting only the last pipe. [02:08] abentley: Yeah, I could see doing that too. [02:11] poolie: I'll look - one moment [02:20] lifeless: nice mail re bugs; thanks [02:21] poolie: there's no separate design doc to my knowledge. There's pieces that may help though ... [02:21] (1) http://bazaar-vcs.org/LineEndings/Roadmap [02:21] (2) bzrlib/filters/__init.__.py docstring [02:21] poolie: anytime [02:21] poolie: all it takes is a good 1/2 hour chat :P [02:22] (3) bzrlib/dirstate/SHA1Provider class docstrings [02:23] (4) I'm sure there's useful tidbits in various email threads as well fwiw (not that they count as doc) [02:31] igc, thanks [02:31] i might provide a bit of an overview or fusion of them [02:43] Hmm, the -s option to selftest seems to be broken. [02:43] spiv: fixed [02:43] Or the aliases, anyway..' [02:43] lifeless: in bzr.dev? [02:44] i my branch, which a local typo stopped landing this morning [02:44] its on its way again now [02:44] Ah, good. Thanks. [02:44] just use a long alias for now [02:45] spiv: https://code.edge.launchpad.net/~lifeless/bzr/test-speed/+merge/10633 [02:45] while U wait [02:46] Yeah, I'm using the full python name for now. [02:50] spiv: so two things [02:50] 1) ICanHazReview [02:50] I waved that branch in front of poolie, but I suspect you'll have more immediate interest in it, given you're working on perf [02:51] 2) self.make_branch_and_tree - It seems that this creates disk branches always, or something. I'm confused about it. I'd like to make a playdate to beat up on it, late this week or early next week. [02:54] spiv: ^ [02:54] lifeless: this is an interesting case for wanting some kind of ad-hoc dependency injection to tests [02:54] I haven't looked at make_branch_and_tree recently, but it usually does confuse and vex me when I do. [02:54] poolie: your branch [02:54] ie i'd like to say, "run everything with crlf conversion turned on" and see what fails [02:54] ? [02:54] this meaning content filtering [02:54] poolie: I agree. broadly 'parameterise everything in this dimension' [02:55] obviously that would require the tests be written in a way to work with that [02:55] so you could not just do it now very easily [02:55] yes, words out of my mouth. [02:57] lifeless: looking at your branch now [02:57] danke [03:13] igc, what i have so far is http://pastebin.ubuntu.com/259053/ [03:13] do you see anything wrong? [03:19] polie: I'll take a look [03:19] spiv: ping [03:19] spiv: when adding remoting of exceptions, do you test them? [03:20] or just make-it-work and depend on tests that build on that ? [03:20] lifeless: I try to test them [03:21] I don't think there's perfect coverage [03:21] I'm just looking up the relevant tests. [03:21] I'm adding IncompatibleRepositories [03:22] There's test_remote.TestErrorTranslationSuccess for the client-side [03:22] poolie: that's excellent - thanks [03:22] q [03:22] thanks [03:23] poolie: I particularly like the clarification re content-only, not tree munging [03:23] mm [03:23] it would be interesting to do that later [03:23] poolie: I'm *not* volunteering for that one fwiw :-) [03:24] :) [03:24] And there's some per-request error serialisation tests in test_smart. [03:24] poolie: I'm planning to fix the current content filtering bugs real soon now and then never touch it again :-) [03:24] ok [03:25] let's talk, later [03:25] maybe after this bug i'll understand it better [03:25] this doc is yak-shaving for bug 415508 [03:25] Launchpad bug 415508 in bzr "Content filtering breaks commit w/ merge parents" [Critical,In progress] https://launchpad.net/bugs/415508 [03:26] I don't think I have direct tests for the generic server-side serialisation of various exceptions (bzrlib.smart.requests._translate_error), although I do have tests that translation will occur (even when during streamed bodies etc). [03:26] Those cases are probably covered indirectly, though. [03:27] poolie: understood. the one I need to finish fixing is bug 385879 [03:27] Launchpad bug 385879 in bzr "EOL filter only applied to files when first checked out" [High,In progress] https://launchpad.net/bugs/385879 [03:30] * igc lunch [03:33] spiv: so [03:33] spiv: rich objects [03:33] do we flatten to strings and keep them that way [03:33] or do we try to reconstruct [in these exceptions] [03:41] Command 'pqm-submmit' not found, perhaps you meant 'pqm-submit'? [y/n]: y [03:41] :) [03:42] poolie: I'm halt()ing for work. Hopefully I'll sleep more tonight [03:50] lifeless: we try to reconstruct some things [03:50] lifeless: e.g. if we already have a Branch or Repository locally, we may as well use that. [03:50] lifeless: I don't think there's a firm policy yet. [03:51] spiv: I'm dealing with Repository here, and won't have at either of them. In fact, one won't exist cause it will be deleted :P [03:51] At the moment it's really been driven by what the individual exceptions require/expect. [03:51] spiv: I'm inclined to coerce this one down to strings and stay there [03:52] I'm starting to think I should be more inclined to adjust the exception classes than adjust the error deserialisation to suit them, although I don't have any specific cases in mind. [03:52] That's ok with me, although I suggest making it explicit in the exception class that it has strings rather than repo instances. [03:52] Or at least, that it can have. [03:53] sure [03:53] tomorrow :) [03:53] Enjoy your afternoon :) [03:54] you'll probably get to enjoy this sort of schedule soon :P [03:54] waking @ 4 that is [03:54] Heh. [03:55] If upstairs keeps deciding that hammering things at 1am is a great idea, I won't even have to wait ;) [03:55] >< [04:44] ok switching machines === poolie changed the topic of #bzr to: Bazaar version control system | 1.18 final released soon | try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ [04:51] igc: mini-review wanted on http://bazaar.launchpad.net/~mbp/bzr/doc/revision/4636 [04:51] just a few more additions beyond what i showed you before [04:54] moved to https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/10638 === gorozco is now known as p4tux [05:11] igc, it seems like what we need for bug 415508 is for commit to say to the wt: give me the hash of the canonical form of this file iff you know it without reading the whole file [05:11] Launchpad bug 415508 in bzr "Content filtering breaks commit w/ merge parents" [Critical,In progress] https://launchpad.net/bugs/415508 [05:20] back [05:20] poolie: I'll take a look now [05:33] igc: sadly the dirstate.py code seems to assume the stat size is the same as the size column [05:33] so we can't rely on the value cached there to be the size of the canonical form [05:48] poolie: where does it still do that? [05:48] add() [05:49] and py_update_entry [05:49] * igc looks [05:50] and the pyrex update_entry [05:59] igc: what do you think? [06:00] that code might not be active on an important path i suppose [06:01] iter_changes [06:01] poolie: starting with your doc patch ... [06:01] I'm not sure the comment about the UI is right [06:01] it would be worth a smoke test to make sure iter_changes with size changing filters returns the right size [06:01] e.g. diff ought to show ... [06:02] how the canonical form changes [06:02] ok, does it? [06:02] that's painfully for external diff tools but the right thing IMO [06:02] i'm trying to document what does happen more than what should happen [06:02] poolie: yes, I think diff does [06:03] also export dumps the canonical format ... [06:03] though it has an option to apply filters to the output [06:05] poolie: so I'll approve your doc patch with those tweaks [06:05] so, maybe i shouldn't generalize, and just say that different commands might have different defaults? [06:05] or do they all default to the canonical form? [06:06] also i'll have to update it about dirstate, assuming that's correct that it's not always storing the canonical size [06:06] poolie: all canonical to my knowledge [06:07] wrt dirstate, I *thought* we had py_update_entry covered and the pyrex implementation [06:08] add() I can't recall changing, though the docstring is explicit about the fingerprint applying to the conical form === abentley1 is now known as abentley [06:10] right, but they are using st_size [06:13] i haven't actually proved it's wrong but they do seem to be accessing something they should not [06:13] test_intertree tests both implementations for iter_changes [06:20] lifeless/igc: teddybear re testing this: [06:20] this being the actual originally reported bug, that multiple commits here store multiple copies even when the canonical form hasn't changed [06:20] i think we are lacking smoke tests here [06:20] or integration tests for all of content filtering [06:22] but probably it also needs a more localized test for the specific change to record_entry_contents [06:22] and we could do that in isolation by just feeding it pre-canned content summaries, along with a fake tree [06:23] and then we'd observe what file graph it eventually writes out [06:24] so [06:24] the bug was in tree - it exposed data inconsistent with its model [06:25] but we're changing record_entry to stop using that exposed data, because exposing the right data is too big a change [or something] [06:25] so, if the new API doesn't have flaky data I don't think we need any new record_changes tests [06:26] actually it's too expensive [06:26] the altered existing ones are _very_ comprehensive. [06:26] poolie: re expensive - we have a size field, we could write the canonical size there when we determine the canonical hash. [06:26] so [06:26] we could [06:27] and on stat cache misses we'd read the file and figure out the right canonical hash - thats not so bad [06:27] we'd have to either detect existing dirstates that have it wrong, or bump the version, or tolerate it sometimes being wrong til people's dirstate gets rewritten [06:27] the last of those might be ok [06:27] thats all true. I'm not meaning to judge the solution. [06:27] just teddybearing where we need to test. [06:27] i'd kind of like to do it, but not as part of this change [06:28] we are changing record_entry; but we're changing it in a way consistent with its tests. [06:28] bbiab [06:28] maybe, depending what ian says, i'll file a bug for that [06:28] cheerio [06:28] we're also changing tree, with the new api. We should test *there* on both filtered and unfiltered [06:28] lifeless: anyhow, it's expensive and not very useful [06:28] mm, i have a test for it [06:29] not very useful because knowing the size doesn't help commit very much [06:29] do we need glue to test that record_entry does the right thing when given data that we've seperately tested is canonical? [06:29] if it's the same it still needs to check the hash, and if it's different it needs to read the whole thing [06:30] i guess i'm feeling the need for an overall integration test [06:30] or smoke test [06:30] there don't seem to be any/many for commit with content filtering [06:30] mmm, I think we don't :- if anything we'd want a test that the interface used by record_entry is actually the tree one, but in fact record_entry takes the result generated by the commit code [06:30] maybe i'll put this up and see what happens [06:31] so a test to close the loop would be test that a) commit calls tree.NEWAPI and then calls record_entry(...NEWAPIRESULT) [06:32] neither of which need to hit disk or exercise the whole stack. And with that test changes to commit to not use NEWAPI will show up, and we know (because the repository tests do this) that record_changes is compatible with the NEWAPI signature [06:32] YMMV, Just my thoughts, etc. [06:36] mm [06:36] i agree with testing bits in isolation [06:36] i guess i just feel like it can miss the big picture [06:36] anyhow https://code.edge.launchpad.net/~mbp/bzr/415508-content-filtering/+merge/10640 [06:39] back [07:05] hi all [07:07] hello vila [07:07] hmm, someone broke the tests on leopard.... [07:08] igc, feel free to say "nothing" but what do you think about smoke tests for content filtering? [07:08] ha ha ! no paramiko on that slave, some test didn't check its dependencies :) [07:08] poolie: I feel we need them [07:09] it's the kind of thing that would be nice to write in a (whisper it) doctest-like mode [07:09] narrative mode [07:09] poolie: but I agree with lifeless about making sure we're testing the low level interaction for this particular bug [07:09] mm [07:09] it's not either or [07:09] poolie: hehe, no problem wrote both kind of tests :) [07:09] it would be slow and clumsy to test everything that way [07:10] poolie: I'm a fan of high level tests because it's end-to-end that ultimately matters [07:10] poolie: but good quality comes from checking each layer is doing it's bit correctly as well [07:11] igc: it's not either or, but high level tests tends to leave *bug* holes in the coverage [07:11] vila: right [07:11] s/bug/big/ funny typo :) [07:11] vila: and low-level ones alone leave integration holes so either-or is not the answer! [07:11] Hello there, can someone please explain how I can set a tag for a particular revision. I did "bzr help tag" but did not quite get ot. [07:11] *it [07:12] to tag the current revision ... [07:12] igc: I find the integration holes easier to deal with... :) [07:12] bzr tag xxx [07:12] to tags an explicit revision ... [07:12] bzr tag -rN yyy [07:12] al-maisan: ^^^ [07:13] igc: thanks, will try that. [07:13] well i guess it was a silly question [07:13] i was actually wanting to ask "why don't we have them" and have the answer not be "cos ian got sick and the rest of us dropped the ball" [07:13] :-} [07:13] vila, so what's up next for you? [07:14] poolie: today: fix the leopard regression and try to package a new bzr-gtk :-/ [07:14] The later is required as the last release version don't work with 1.18.... [07:15] and I'll try to create the PPAs that time [07:15] so, I think we have many more high level tests that we need at the moment. Thats not a reason not to write ones we need. But I feel an urge to be parsimonious about adding them. [07:15] lifeless: agreed, and many of them should be turned into lower level ones too [07:16] i think it's unbalanced [07:16] like here we have a major feature and there's not really any integration tests [07:16] i think in some older tests there are probably too many high level tests [07:17] and the ones we do have are probably too slow to run and too hard to debug [07:29] hi igc [07:30] hi bialix: no explorer work so far today - hopefully tonight after dinner [07:30] ok [07:30] you answer my question :-) [07:31] vila: bonjour? [07:31] bialix: still replying to emails in my queue and tying up other stuff :-( [07:31] igc: don't worry [07:32] igc: I'm just want to know about installer [07:32] hello bialix ! [07:32] igc: btw, quick answer on your q in bzr-windows about msi: I think the answer is NO [07:32] vila: hello! [07:33] well my plan is to package 0.7 tonight and hope someone picks up the ball and gets it into karmic [07:33] vila: I'd like to beg you again about merging my patch (now patch for paramiko default) [07:34] bialix: was on my list :-( [07:34] vila: https://code.launchpad.net/~bialix/bzr/win32-paramiko-default/+merge/10563 [07:34] vila: I'm sorry? [07:34] igc: I can't help with karmic. Gary could, but it's hard to catch him [07:35] from irclogs he was here this night [07:37] hello bialix [07:38] hello poolie [07:38] how's 2.0beta going? [07:48] FWIW, I'll pretty much always write high-level tests, 'cuz it's very easy to say what I want like that, compared to faking my way through the API... [07:50] fullermd: And you do right ! [07:51] I mean, it's a very good way to start, others can then rewrite your tests into lower levels ones [07:53] I often start by writing a *shell* script to reproduce a bug (based on a skeleton I derived from one of your bug reports, just because it was using 'bzr' as a parameter to help test against various versions (among other tricks) [07:53] once I Isolate the problem enough I can write more precise tests. [07:54] There has been discussions (I hope it wasn't in a code review :-/) about defining some kind of easy to use language to allow people to write tests more easily, so the idea in the air :) [07:54] is in the air even (does it make sense in english ?) [07:54] Actually, IIRC, I started doing that after I got all riled up about some bug that turned out to be fallout from one of my aliases... [07:55] So having a var I could stick --no-aliases in was a "Don't be a dumbass in public" mechanism ;) [07:55] I remember this idea was first developed by James Blackwell (?) [08:02] bialix: sent to pqm [08:02] vila: thanks! and 2.0 branch too? [08:02] bialix: against trunk though [08:03] poolie said in ML 2.0 branch is separate now [08:03] indeed [08:03] you need explicit approval to land there I think [08:04] or the RM will cherry-pick it ? [08:04] * fullermd dreads 2.0 betas... [08:04] Once they start coming out I have to make packaging decisions :( [08:04] poolie: waht about merging paramiko-default patch to 2.0? [08:04] poolie: what about merging paramiko-default patch to 2.0? [08:05] fullermd: yeah, yeah, people keep being afraid, but the truth is, we generally fail in unexpected places anyway but rarely in parts people were afraid about :-D [08:07] fullermd: and if you could send me a short mail pointing to the better instructions to install the most important xBSD distro to test against, I could add it to the test farm one of these days... [08:07] fullermd: It doesn't have to be detailed as long as it's: download the iso here, boot, click, click, done :) [08:08] bialix: nominate it for 2.0 in launchpad [08:08] or target it [08:08] nominate patch? [08:08] or nominate bug? [08:08] bialix: and ensures that it can be merged cleanly into the 2.0 branch (that will help) [08:08] bialix: bug [08:09] vila: it will be merged cleanly yes [08:09] vila: *blink* Non sequitor? Or did I forget a conversation? [08:09] bialix: so that it will either: 1) be merged in 2.0 2) be re-targeted [08:09] vila: unless you guys doing extra NEWS items and they are always conflicts [08:09] forget about NEWS conflicts, there is no way the RM can avoid handling them :) [08:10] vila, lifeless: I have no control over targetting bugs, so... [08:11] fullermd: Clearly non sequitur, but I wanted to ask for a long time, now, was as good as any other time :) [08:11] bug https://bugs.launchpad.net/bzr/+bug/414743 nominated [08:11] bialix: are you kidding ? [08:11] Launchpad bug 414743 in bzr "paramiko should be default client for Windows" [High,Fix committed] [08:11] vila: about what? [08:12] about nominating bugs, just select the milestone, *that's* nominating :) [08:12] wow, you're not part of bzr devs team on launchpad... :-/ [08:12] vila: I'm not part of bzr team @ lp. so I can't [08:13] yes [08:13] bialix: nice picture though :D [08:13] thanks [08:13] also is 2 years old [08:13] oh, and I was wrong, nominating is a precise meaning, you seem to have done it anyway [08:14] * bialix now is older and not so nice :-P [08:14] Ooh, that's a good excuse. I'm gonna use that. [08:17] fullermd: always happy to help (tm) [08:17] I meant bialix's :) [08:18] sorry? [08:18] I'll try throwing something a sketch together for you. I only really know Free, though; it's been 10 years or so since I touched Net/Open. [08:18] "older and not so nice" [08:18] fullermd: whatever you know the best [08:19] Free is FreeBSD? [08:19] Some of the test failures, like the '..' one, are so weird I can't believe it actually works anywhere, so that's an easily portable fix. [08:19] The one with the disappearing revs, I have NFC though. I don't even have a guess as to the culprit, so I dunno how portable the failure would even be. [08:19] * fullermd nods at bialix. [08:20] fullermd: you have *fixes* for test failures on FreeBSD ???? [08:20] No, but the '..' would be pretty trivial. [08:20] fullermd: sorry, it seems I don't follow your last jokes [08:20] * bialix trying to steal .desktop file from bzr-gtk [08:20] bialix: Don't worry, it wasn't a very good one. [08:21] fullermd: ok, because I like your jokes [08:21] anybody knows something] about .desktop files? [08:21] anybody knows something about .desktop files? [08:22] Heck, I use ctwm; I don't even know anything about desktops :] [08:23] * bialix even don't know what is ctwm and fear to ask [08:24] The only proper way to run a GUI, naturally. [08:24] bialix: pre-historic window manager, a bit younger than twm [08:25] Pre-historic?! Bah. Kids these days... [08:25] lol [08:25] I'll have you know that its latest commit was in June of this year. [08:26] fullermd: sorry, I'm a bit grumpy because I played with gentto and went as far as twm running... :-D [08:26] yeah gentto, that's it [08:26] I hear gentto comes with a good hhtp server. [08:27] LOL [08:28] bialix: the .desktop spec is fairly clear; what are you having trouble with? [08:28] AfC: Icon [08:28] I've hacked something based on olive-gtk.desktop and pushed to trunk [08:28] bialix: Should be just [08:28] anybody able to test? [08:29]