| poolie | lifeless: did you revert the bug policy change? | 00:02 |
|---|---|---|
| lifeless | yes | 00:11 |
| lifeless | about 5am or so | 00:11 |
| lifeless | its now blocked on you, aaron's approve vote notwithstanding | 00:14 |
| poolie | i can't go for "use either one randomly" | 00:17 |
| poolie | i could be convinced to use it as Ubuntu does, meaning that random users can't "really" confirm it | 00:18 |
| poolie | but that feels more heaviweight than necessary | 00:18 |
| poolie | especially if you think about bugs flipping incomplete/confirmed | 00:18 |
| poolie | "somebody does it" or even "lots of people do it" is not very convincing | 00:18 |
| poolie | lots of people use 8-space tabs but i don't want random bzrlib files being done with 8-space tabs | 00:19 |
| poolie | mm | 00:21 |
| lifeless | 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 |
| lifeless | 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 |
| poolie | the rule being "don't use triaged"? | 00:21 |
| lifeless | a rule we haven't been honouring for some time, based on bug database evidence | 00:23 |
| poolie | sheesh | 00:23 |
| igc | morning | 00:23 |
| lifeless | if it hasn't been causing harm, I think we should relax the rule | 00:23 |
| igc | hi poolie, lifeless, jam | 00:23 |
| lifeless | hi igc | 00:24 |
| poolie | also, according to bug database evidence, we have lots of bugs, therefore we should keep having them? | 00:24 |
| poolie | be serious | 00:24 |
| poolie | hi igc | 00:24 |
| lifeless | sheese yourself, totally useless analogy - not the same thing at all. | 00:25 |
| * lifeless goes back to fixing bug 393677 | 00:25 | |
| ubottu | 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:26 |
| jam | 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 | 00:55 |
| poolie | np | 01:25 |
| poolie | jam, ping me here if you like | 01:25 |
| garyvdm | Hi igc. | 01:26 |
| igc | hi garyvdm! | 01:26 |
| garyvdm | I've been working on a blue print for a text conflict resolving tool. | 01:26 |
| garyvdm | It's not finished yet, but there lots done so far. | 01:27 |
| garyvdm | http://bazaar-vcs.org/qbzr/Blueprint/diffmerge | 01:27 |
| poolie | ooh | 01:28 |
| garyvdm | Just wanted to bring you attention to it. I would like to discusses it in detail post 2.0 | 01:28 |
| garyvdm | And with vila | 01:28 |
| garyvdm | Hi poolie | 01:28 |
| garyvdm | igc: The bits I still need to spec out is the intergration with annotate and log. | 01:29 |
| poolie | automatically helping you find the context for the merge would be excelletn | 01:30 |
| fullermd | igc: Hey, quick fast-import Q... does it rely on essentially holding the stream in memory? | 01:30 |
| lifeless | fullermd: no | 01:31 |
| lifeless | little bits of | 01:31 |
| lifeless | memory issues? | 01:31 |
| igc | fullermd: no | 01:31 |
| garyvdm | Good night all. | 01:31 |
| fullermd | 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 |
| lifeless | fullermd: heh | 01:32 |
| lifeless | no | 01:32 |
| lifeless | ports? | 01:32 |
| igc | fullermd: that's a baby :-) | 01:32 |
| fullermd | No, ports is still in CVS. src is in SVN. | 01:32 |
| fullermd | I still don't have the guts to tackle ports :p | 01:33 |
| lifeless | \o/ | 01:33 |
| igc | fullermd: the emacs fastimport dump is 7.5GB gzipped | 01:33 |
| lifeless | fullermd: does it have modules at all? | 01:33 |
| fullermd | It _is_ a module ;) | 01:34 |
| igc | 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 |
| igc | fullermd: that's a bug somewhere is the python-subversion bindings I think | 01:35 |
| fullermd | Funny, I was thinking that the other week when I glanced at what was needed for it... | 01:36 |
| igc | fullermd: but it often works (and there's a svn-fast-export.c that doesn't have the issue if it does) | 01:36 |
| fullermd | "Subversion python bindings? You mean the ones that jelmer gave up on using 'cuz they were too buggy?" | 01:36 |
| igc | fullermd: there's at least 3 binding to my knowledge, so probably but not sure | 01:37 |
| igc | bindings | 01:37 |
| lifeless | python-subversion | 01:37 |
| lifeless | subvertpy | 01:37 |
| lifeless | and pysubversion | 01:37 |
| lifeless | IIRC | 01:37 |
| fullermd | So much simpler with CVS, where everybody gets to just implement their own RCS file parser... | 01:38 |
| jkakar | abentley: I've been using your pipeline plugin since yesterday and I love it. Thanks a lot! :) | 01:47 |
| poolie | igc, i thought you wrote some developer docs about content filtering but i don't see them in the tree | 01:54 |
| poolie | did they get lost, or was it perhaps just a mail thread that i was thinking of? | 01:54 |
| lifeless | 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 |
| lifeless | abentley: just giving you a heads up | 01:55 |
| === Noldorin_ is now known as Noldorin | ||
| abentley | jkakar: Cool! | 02:00 |
| jkakar | abentley: I have a pipeline with 8 branches and am happily making progress jumping between them. | 02:02 |
| abentley | 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:03 |
| abentley | jkakar: Wow, that might be the deepest bzr pipeline ever. :-) | 02:04 |
| jkakar | abentley: Heh. :) | 02:05 |
| jkakar | abentley: I'm refactoring a bunch of existing code that has a nice hierarchy of objects already implemented. | 02:05 |
| jkakar | 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:06 |
| abentley | 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:07 |
| jkakar | abentley: Yeah, I could see doing that too. | 02:08 |
| igc | poolie: I'll look - one moment | 02:11 |
| poolie | lifeless: nice mail re bugs; thanks | 02:20 |
| igc | poolie: there's no separate design doc to my knowledge. There's pieces that may help though ... | 02:21 |
| igc | (1) http://bazaar-vcs.org/LineEndings/Roadmap | 02:21 |
| igc | (2) bzrlib/filters/__init.__.py docstring | 02:21 |
| lifeless | poolie: anytime | 02:21 |
| lifeless | poolie: all it takes is a good 1/2 hour chat :P | 02:21 |
| igc | (3) bzrlib/dirstate/SHA1Provider class docstrings | 02:22 |
| igc | (4) I'm sure there's useful tidbits in various email threads as well fwiw (not that they count as doc) | 02:23 |
| poolie | igc, thanks | 02:31 |
| poolie | i might provide a bit of an overview or fusion of them | 02:31 |
| spiv | Hmm, the -s option to selftest seems to be broken. | 02:43 |
| lifeless | spiv: fixed | 02:43 |
| spiv | Or the aliases, anyway..' | 02:43 |
| spiv | lifeless: in bzr.dev? | 02:43 |
| lifeless | i my branch, which a local typo stopped landing this morning | 02:44 |
| lifeless | its on its way again now | 02:44 |
| spiv | Ah, good. Thanks. | 02:44 |
| lifeless | just use a long alias for now | 02:44 |
| lifeless | spiv: https://code.edge.launchpad.net/~lifeless/bzr/test-speed/+merge/10633 | 02:45 |
| lifeless | while U wait | 02:45 |
| spiv | Yeah, I'm using the full python name for now. | 02:46 |
| lifeless | spiv: so two things | 02:50 |
| lifeless | 1) ICanHazReview | 02:50 |
| lifeless | 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:50 |
| lifeless | 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:51 |
| lifeless | spiv: ^ | 02:54 |
| poolie | lifeless: this is an interesting case for wanting some kind of ad-hoc dependency injection to tests | 02:54 |
| spiv | I haven't looked at make_branch_and_tree recently, but it usually does confuse and vex me when I do. | 02:54 |
| lifeless | poolie: your branch | 02:54 |
| poolie | ie i'd like to say, "run everything with crlf conversion turned on" and see what fails | 02:54 |
| lifeless | ? | 02:54 |
| poolie | this meaning content filtering | 02:54 |
| lifeless | poolie: I agree. broadly 'parameterise everything in this dimension' | 02:54 |
| poolie | obviously that would require the tests be written in a way to work with that | 02:55 |
| poolie | so you could not just do it now very easily | 02:55 |
| lifeless | yes, words out of my mouth. | 02:55 |
| spiv | lifeless: looking at your branch now | 02:57 |
| lifeless | danke | 02:57 |
| poolie | igc, what i have so far is http://pastebin.ubuntu.com/259053/ | 03:13 |
| poolie | do you see anything wrong? | 03:13 |
| igc | polie: I'll take a look | 03:19 |
| lifeless | spiv: ping | 03:19 |
| lifeless | spiv: when adding remoting of exceptions, do you test them? | 03:19 |
| lifeless | or just make-it-work and depend on tests that build on that ? | 03:20 |
| spiv | lifeless: I try to test them | 03:20 |
| spiv | I don't think there's perfect coverage | 03:21 |
| spiv | I'm just looking up the relevant tests. | 03:21 |
| lifeless | I'm adding IncompatibleRepositories | 03:21 |
| spiv | There's test_remote.TestErrorTranslationSuccess for the client-side | 03:22 |
| igc | poolie: that's excellent - thanks | 03:22 |
| lifeless | q | 03:22 |
| poolie | thanks | 03:22 |
| igc | poolie: I particularly like the clarification re content-only, not tree munging | 03:23 |
| poolie | mm | 03:23 |
| poolie | it would be interesting to do that later | 03:23 |
| igc | poolie: I'm *not* volunteering for that one fwiw :-) | 03:23 |
| poolie | :) | 03:24 |
| spiv | And there's some per-request error serialisation tests in test_smart. | 03:24 |
| igc | poolie: I'm planning to fix the current content filtering bugs real soon now and then never touch it again :-) | 03:24 |
| poolie | ok | 03:24 |
| poolie | let's talk, later | 03:25 |
| poolie | maybe after this bug i'll understand it better | 03:25 |
| poolie | this doc is yak-shaving for bug 415508 | 03:25 |
| ubottu | Launchpad bug 415508 in bzr "Content filtering breaks commit w/ merge parents" [Critical,In progress] https://launchpad.net/bugs/415508 | 03:25 |
| spiv | 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 |
| spiv | Those cases are probably covered indirectly, though. | 03:26 |
| igc | poolie: understood. the one I need to finish fixing is bug 385879 | 03:27 |
| ubottu | Launchpad bug 385879 in bzr "EOL filter only applied to files when first checked out" [High,In progress] https://launchpad.net/bugs/385879 | 03:27 |
| * igc lunch | 03:30 | |
| lifeless | spiv: so | 03:33 |
| lifeless | spiv: rich objects | 03:33 |
| lifeless | do we flatten to strings and keep them that way | 03:33 |
| lifeless | or do we try to reconstruct [in these exceptions] | 03:33 |
| lifeless | Command 'pqm-submmit' not found, perhaps you meant 'pqm-submit'? [y/n]: y | 03:41 |
| lifeless | :) | 03:41 |
| lifeless | poolie: I'm halt()ing for work. Hopefully I'll sleep more tonight | 03:42 |
| spiv | lifeless: we try to reconstruct some things | 03:50 |
| spiv | lifeless: e.g. if we already have a Branch or Repository locally, we may as well use that. | 03:50 |
| spiv | lifeless: I don't think there's a firm policy yet. | 03:50 |
| lifeless | 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 |
| spiv | At the moment it's really been driven by what the individual exceptions require/expect. | 03:51 |
| lifeless | spiv: I'm inclined to coerce this one down to strings and stay there | 03:51 |
| spiv | 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 |
| spiv | 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 |
| spiv | Or at least, that it can have. | 03:52 |
| lifeless | sure | 03:53 |
| lifeless | tomorrow :) | 03:53 |
| spiv | Enjoy your afternoon :) | 03:53 |
| lifeless | you'll probably get to enjoy this sort of schedule soon :P | 03:54 |
| lifeless | waking @ 4 that is | 03:54 |
| spiv | Heh. | 03:54 |
| spiv | If upstairs keeps deciding that hammering things at 1am is a great idea, I won't even have to wait ;) | 03:55 |
| lifeless | >< | 03:55 |
| poolie | ok switching machines | 04:44 |
| === 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/ | ||
| poolie | igc: mini-review wanted on http://bazaar.launchpad.net/~mbp/bzr/doc/revision/4636 | 04:51 |
| poolie | just a few more additions beyond what i showed you before | 04:51 |
| poolie | moved to https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/10638 | 04:54 |
| === gorozco is now known as p4tux | ||
| poolie | 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 |
| ubottu | Launchpad bug 415508 in bzr "Content filtering breaks commit w/ merge parents" [Critical,In progress] https://launchpad.net/bugs/415508 | 05:11 |
| igc | back | 05:20 |
| igc | poolie: I'll take a look now | 05:20 |
| poolie | igc: sadly the dirstate.py code seems to assume the stat size is the same as the size column | 05:33 |
| poolie | so we can't rely on the value cached there to be the size of the canonical form | 05:33 |
| igc | poolie: where does it still do that? | 05:48 |
| poolie | add() | 05:48 |
| poolie | and py_update_entry | 05:49 |
| * igc looks | 05:49 | |
| poolie | and the pyrex update_entry | 05:50 |
| poolie | igc: what do you think? | 05:59 |
| poolie | that code might not be active on an important path i suppose | 06:00 |
| lifeless | iter_changes | 06:01 |
| igc | poolie: starting with your doc patch ... | 06:01 |
| igc | I'm not sure the comment about the UI is right | 06:01 |
| lifeless | it would be worth a smoke test to make sure iter_changes with size changing filters returns the right size | 06:01 |
| igc | e.g. diff ought to show ... | 06:01 |
| igc | how the canonical form changes | 06:02 |
| poolie | ok, does it? | 06:02 |
| igc | that's painfully for external diff tools but the right thing IMO | 06:02 |
| poolie | i'm trying to document what does happen more than what should happen | 06:02 |
| igc | poolie: yes, I think diff does | 06:02 |
| igc | also export dumps the canonical format ... | 06:03 |
| igc | though it has an option to apply filters to the output | 06:03 |
| igc | poolie: so I'll approve your doc patch with those tweaks | 06:05 |
| poolie | so, maybe i shouldn't generalize, and just say that different commands might have different defaults? | 06:05 |
| poolie | or do they all default to the canonical form? | 06:05 |
| poolie | also i'll have to update it about dirstate, assuming that's correct that it's not always storing the canonical size | 06:06 |
| igc | poolie: all canonical to my knowledge | 06:06 |
| igc | wrt dirstate, I *thought* we had py_update_entry covered and the pyrex implementation | 06:07 |
| igc | add() I can't recall changing, though the docstring is explicit about the fingerprint applying to the conical form | 06:08 |
| === abentley1 is now known as abentley | ||
| poolie | right, but they are using st_size | 06:10 |
| poolie | i haven't actually proved it's wrong but they do seem to be accessing something they should not | 06:13 |
| lifeless | test_intertree tests both implementations for iter_changes | 06:13 |
| poolie | lifeless/igc: teddybear re testing this: | 06:20 |
| poolie | this being the actual originally reported bug, that multiple commits here store multiple copies even when the canonical form hasn't changed | 06:20 |
| poolie | i think we are lacking smoke tests here | 06:20 |
| poolie | or integration tests for all of content filtering | 06:20 |
| poolie | but probably it also needs a more localized test for the specific change to record_entry_contents | 06:22 |
| poolie | and we could do that in isolation by just feeding it pre-canned content summaries, along with a fake tree | 06:22 |
| poolie | and then we'd observe what file graph it eventually writes out | 06:23 |
| lifeless | so | 06:24 |
| lifeless | the bug was in tree - it exposed data inconsistent with its model | 06:24 |
| lifeless | 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 |
| lifeless | so, if the new API doesn't have flaky data I don't think we need any new record_changes tests | 06:25 |
| poolie | actually it's too expensive | 06:26 |
| lifeless | the altered existing ones are _very_ comprehensive. | 06:26 |
| lifeless | poolie: re expensive - we have a size field, we could write the canonical size there when we determine the canonical hash. | 06:26 |
| poolie | so | 06:26 |
| poolie | we could | 06:26 |
| lifeless | and on stat cache misses we'd read the file and figure out the right canonical hash - thats not so bad | 06:27 |
| poolie | 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 |
| poolie | the last of those might be ok | 06:27 |
| lifeless | thats all true. I'm not meaning to judge the solution. | 06:27 |
| lifeless | just teddybearing where we need to test. | 06:27 |
| poolie | i'd kind of like to do it, but not as part of this change | 06:27 |
| lifeless | we are changing record_entry; but we're changing it in a way consistent with its tests. | 06:28 |
| igc | bbiab | 06:28 |
| poolie | maybe, depending what ian says, i'll file a bug for that | 06:28 |
| poolie | cheerio | 06:28 |
| lifeless | we're also changing tree, with the new api. We should test *there* on both filtered and unfiltered | 06:28 |
| poolie | lifeless: anyhow, it's expensive and not very useful | 06:28 |
| poolie | mm, i have a test for it | 06:28 |
| poolie | not very useful because knowing the size doesn't help commit very much | 06:29 |
| lifeless | 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 |
| poolie | 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:29 |
| poolie | i guess i'm feeling the need for an overall integration test | 06:30 |
| poolie | or smoke test | 06:30 |
| poolie | there don't seem to be any/many for commit with content filtering | 06:30 |
| lifeless | 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 |
| poolie | maybe i'll put this up and see what happens | 06:30 |
| lifeless | so a test to close the loop would be test that a) commit calls tree.NEWAPI and then calls record_entry(...NEWAPIRESULT) | 06:31 |
| lifeless | 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 |
| lifeless | YMMV, Just my thoughts, etc. | 06:32 |
| poolie | mm | 06:36 |
| poolie | i agree with testing bits in isolation | 06:36 |
| poolie | i guess i just feel like it can miss the big picture | 06:36 |
| poolie | anyhow https://code.edge.launchpad.net/~mbp/bzr/415508-content-filtering/+merge/10640 | 06:36 |
| igc | back | 06:39 |
| vila | hi all | 07:05 |
| poolie | hello vila | 07:07 |
| vila | hmm, someone broke the tests on leopard.... | 07:07 |
| poolie | igc, feel free to say "nothing" but what do you think about smoke tests for content filtering? | 07:08 |
| vila | ha ha ! no paramiko on that slave, some test didn't check its dependencies :) | 07:08 |
| igc | poolie: I feel we need them | 07:08 |
| poolie | it's the kind of thing that would be nice to write in a (whisper it) doctest-like mode | 07:09 |
| poolie | narrative mode | 07:09 |
| igc | poolie: but I agree with lifeless about making sure we're testing the low level interaction for this particular bug | 07:09 |
| poolie | mm | 07:09 |
| poolie | it's not either or | 07:09 |
| vila | poolie: hehe, no problem wrote both kind of tests :) | 07:09 |
| poolie | it would be slow and clumsy to test everything that way | 07:09 |
| igc | poolie: I'm a fan of high level tests because it's end-to-end that ultimately matters | 07:10 |
| igc | poolie: but good quality comes from checking each layer is doing it's bit correctly as well | 07:10 |
| vila | igc: it's not either or, but high level tests tends to leave *bug* holes in the coverage | 07:11 |
| igc | vila: right | 07:11 |
| vila | s/bug/big/ funny typo :) | 07:11 |
| igc | vila: and low-level ones alone leave integration holes so either-or is not the answer! | 07:11 |
| al-maisan | 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 |
| al-maisan | *it | 07:11 |
| igc | to tag the current revision ... | 07:12 |
| vila | igc: I find the integration holes easier to deal with... :) | 07:12 |
| igc | bzr tag xxx | 07:12 |
| igc | to tags an explicit revision ... | 07:12 |
| igc | bzr tag -rN yyy | 07:12 |
| igc | al-maisan: ^^^ | 07:12 |
| al-maisan | igc: thanks, will try that. | 07:13 |
| poolie | well i guess it was a silly question | 07:13 |
| poolie | 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 |
| poolie | :-} | 07:13 |
| poolie | vila, so what's up next for you? | 07:13 |
| vila | poolie: today: fix the leopard regression and try to package a new bzr-gtk :-/ | 07:14 |
| vila | The later is required as the last release version don't work with 1.18.... | 07:14 |
| vila | and I'll try to create the PPAs that time | 07:15 |
| lifeless | 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 |
| vila | lifeless: agreed, and many of them should be turned into lower level ones too | 07:15 |
| poolie | i think it's unbalanced | 07:16 |
| poolie | like here we have a major feature and there's not really any integration tests | 07:16 |
| poolie | i think in some older tests there are probably too many high level tests | 07:16 |
| poolie | and the ones we do have are probably too slow to run and too hard to debug | 07:17 |
| bialix | hi igc | 07:29 |
| igc | hi bialix: no explorer work so far today - hopefully tonight after dinner | 07:30 |
| bialix | ok | 07:30 |
| bialix | you answer my question :-) | 07:30 |
| bialix | vila: bonjour? | 07:31 |
| igc | bialix: still replying to emails in my queue and tying up other stuff :-( | 07:31 |
| bialix | igc: don't worry | 07:31 |
| bialix | igc: I'm just want to know about installer | 07:32 |
| vila | hello bialix ! | 07:32 |
| bialix | igc: btw, quick answer on your q in bzr-windows about msi: I think the answer is NO | 07:32 |
| bialix | vila: hello! | 07:32 |
| igc | well my plan is to package 0.7 tonight and hope someone picks up the ball and gets it into karmic | 07:33 |
| bialix | vila: I'd like to beg you again about merging my patch (now patch for paramiko default) | 07:33 |
| vila | bialix: was on my list :-( | 07:34 |
| bialix | vila: https://code.launchpad.net/~bialix/bzr/win32-paramiko-default/+merge/10563 | 07:34 |
| bialix | vila: I'm sorry? | 07:34 |
| bialix | igc: I can't help with karmic. Gary could, but it's hard to catch him | 07:34 |
| bialix | from irclogs he was here this night | 07:35 |
| poolie | hello bialix | 07:37 |
| bialix | hello poolie | 07:38 |
| bialix | how's 2.0beta going? | 07:38 |
| fullermd | 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:48 |
| vila | fullermd: And you do right ! | 07:50 |
| vila | I mean, it's a very good way to start, others can then rewrite your tests into lower levels ones | 07:51 |
| vila | 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 |
| vila | once I Isolate the problem enough I can write more precise tests. | 07:53 |
| vila | 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 |
| vila | is in the air even (does it make sense in english ?) | 07:54 |
| fullermd | 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:54 |
| fullermd | So having a var I could stick --no-aliases in was a "Don't be a dumbass in public" mechanism ;) | 07:55 |
| bialix | I remember this idea was first developed by James Blackwell (?) | 07:55 |
| vila | bialix: sent to pqm | 08:02 |
| bialix | vila: thanks! and 2.0 branch too? | 08:02 |
| vila | bialix: against trunk though | 08:02 |
| bialix | poolie said in ML 2.0 branch is separate now | 08:03 |
| vila | indeed | 08:03 |
| vila | you need explicit approval to land there I think | 08:03 |
| vila | or the RM will cherry-pick it ? | 08:04 |
| * fullermd dreads 2.0 betas... | 08:04 | |
| fullermd | Once they start coming out I have to make packaging decisions :( | 08:04 |
| bialix | poolie: waht about merging paramiko-default patch to 2.0? | 08:04 |
| bialix | poolie: what about merging paramiko-default patch to 2.0? | 08:04 |
| vila | 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:05 |
| vila | 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 |
| vila | fullermd: It doesn't have to be detailed as long as it's: download the iso here, boot, click, click, done :) | 08:07 |
| lifeless | bialix: nominate it for 2.0 in launchpad | 08:08 |
| lifeless | or target it | 08:08 |
| bialix | nominate patch? | 08:08 |
| bialix | or nominate bug? | 08:08 |
| vila | bialix: and ensures that it can be merged cleanly into the 2.0 branch (that will help) | 08:08 |
| vila | bialix: bug | 08:08 |
| bialix | vila: it will be merged cleanly yes | 08:09 |
| fullermd | vila: *blink* Non sequitor? Or did I forget a conversation? | 08:09 |
| vila | bialix: so that it will either: 1) be merged in 2.0 2) be re-targeted | 08:09 |
| bialix | vila: unless you guys doing extra NEWS items and they are always conflicts | 08:09 |
| vila | forget about NEWS conflicts, there is no way the RM can avoid handling them :) | 08:09 |
| bialix | vila, lifeless: I have no control over targetting bugs, so... | 08:10 |
| vila | fullermd: Clearly non sequitur, but I wanted to ask for a long time, now, was as good as any other time :) | 08:11 |
| bialix | bug https://bugs.launchpad.net/bzr/+bug/414743 nominated | 08:11 |
| vila | bialix: are you kidding ? | 08:11 |
| ubottu | Launchpad bug 414743 in bzr "paramiko should be default client for Windows" [High,Fix committed] | 08:11 |
| bialix | vila: about what? | 08:11 |
| vila | about nominating bugs, just select the milestone, *that's* nominating :) | 08:12 |
| vila | wow, you're not part of bzr devs team on launchpad... :-/ | 08:12 |
| bialix | vila: I'm not part of bzr team @ lp. so I can't | 08:12 |
| bialix | yes | 08:13 |
| vila | bialix: nice picture though :D | 08:13 |
| bialix | thanks | 08:13 |
| bialix | also is 2 years old | 08:13 |
| vila | oh, and I was wrong, nominating is a precise meaning, you seem to have done it anyway | 08:13 |
| * bialix now is older and not so nice :-P | 08:14 | |
| fullermd | Ooh, that's a good excuse. I'm gonna use that. | 08:14 |
| vila | fullermd: always happy to help (tm) | 08:17 |
| fullermd | I meant bialix's :) | 08:17 |
| bialix | sorry? | 08:18 |
| fullermd | 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 |
| fullermd | "older and not so nice" | 08:18 |
| vila | fullermd: whatever you know the best | 08:18 |
| bialix | Free is FreeBSD? | 08:19 |
| fullermd | 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 |
| fullermd | 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:19 | |
| vila | fullermd: you have *fixes* for test failures on FreeBSD ???? | 08:20 |
| fullermd | No, but the '..' would be pretty trivial. | 08:20 |
| bialix | fullermd: sorry, it seems I don't follow your last jokes | 08:20 |
| * bialix trying to steal .desktop file from bzr-gtk | 08:20 | |
| fullermd | bialix: Don't worry, it wasn't a very good one. | 08:20 |
| bialix | fullermd: ok, because I like your jokes | 08:21 |
| bialix | anybody knows something] about .desktop files? | 08:21 |
| bialix | anybody knows something about .desktop files? | 08:21 |
| fullermd | Heck, I use ctwm; I don't even know anything about desktops :] | 08:22 |
| * bialix even don't know what is ctwm and fear to ask | 08:23 | |
| fullermd | The only proper way to run a GUI, naturally. | 08:24 |
| vila | bialix: pre-historic window manager, a bit younger than twm | 08:24 |
| fullermd | Pre-historic?! Bah. Kids these days... | 08:25 |
| bialix | lol | 08:25 |
| fullermd | I'll have you know that its latest commit was in June of this year. | 08:25 |
| vila | fullermd: sorry, I'm a bit grumpy because I played with gentto and went as far as twm running... :-D | 08:26 |
| vila | yeah gentto, that's it | 08:26 |
| fullermd | I hear gentto comes with a good hhtp server. | 08:26 |
| vila | LOL | 08:27 |
| AfC | bialix: the .desktop spec is fairly clear; what are you having trouble with? | 08:28 |
| bialix | AfC: Icon | 08:28 |
| bialix | I've hacked something based on olive-gtk.desktop and pushed to trunk | 08:28 |
| AfC | bialix: Should be just | 08:28 |
| bialix | anybody able to test? | 08:28 |
| AfC | Icon=/fully/qualified/path/to/file.png | 08:29 |
| bialix | AfC: hmm, because bzr-explorer it's a plugin then I dont think I know what will be /fully/qualified/path | 08:30 |
| AfC | I'd show you a working example, but judging by the discourteousness rudeness above, I think we'll skip that. | 08:31 |
| * bialix wonder... | 08:32 | |
| bialix | AfC: I don't quite understand what do you mean | 08:32 |
| AfC | bialix: that was a Gentoo user expressing that he doesn't quite appreciate other people rubbishing the hard work of people who contribute to community distros. | 08:33 |
| bialix | AfC: I'm Windows user/developer | 08:34 |
| bialix | AfC: and I'm native Russian | 08:34 |
| bialix | so if you think I say something wrong -- I'll live with that | 08:35 |
| AfC | bialix: it wasn't you. It was the others. | 08:35 |
| vila | AfC: ohhh, so sorry, that was a joke about me having lost the habit of installing linux the hard way, | 08:35 |
| * bialix feels out of sync | 08:36 | |
| AfC | bialix: but in this case, the working example I was going to show you was in a Gentoo package [to my knowledge it's not packaged in Debian or Ubuntu or Fedora] | 08:36 |
| bialix | I think I'd better skip all this stuff | 08:37 |
| AfC | bialix: but as the others here would just make fun of me if I attempted to show it, I think we'll just move on. | 08:37 |
| vila | Contrast my requirement to fullermd for an install: 'download iso, boot, click , click' and the way Gentoo is installed... different needs, different means, not a critic of the Gentoo community... | 08:37 |
| AfC | bialix: I do remember that http://standards.freedesktop.org/desktop-entry-spec/latest/apa.html was not much help, but http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s02.html does give the rules | 08:41 |
| AfC | bialix: I believe the FHS path for .desktop files is /usr/share/applications | 08:42 |
| AfC | bialix: I have lots of .desktop files there. | 08:42 |
| AfC | bialix: if you're running Microsoft Windows (only) then that won't be of much help to you | 08:43 |
| bialix | AfC: so IIUC it should be done when packaging | 08:43 |
| AfC | bialix: yeah, that gets tricky | 08:43 |
| bialix | AfC: not only | 08:43 |
| bialix | AfC: but bzr development I do only there | 08:43 |
| AfC | bialix: it's one of those things that the program knows the data for, but that needs to get deployed by make install && packaging | 08:43 |
| bialix | AfC: Ok, thanks | 08:43 |
| AfC | bialix: so what I can show you is a Perl script (a ./configure) that writes out a .desktop file at configure time. | 08:44 |
| bialix | I understand now | 08:44 |
| AfC | bialix: see the very end of http://research.operationaldynamics.com/bzr/slashtime/mainline/configure | 08:44 |
| bialix | I think it will be toooo much for me | 08:44 |
| AfC | bialix: `make install` moves that to $(DESTDIR)$(PREFIX)/share/applications | 08:45 |
| AfC | s/that/the .desktop file that outputs/ | 08:45 |
| bialix | I see | 08:46 |
| AfC | bialix: sorry I don't have a cleaner example; most projects do m4 macros or similar template substitution. I did it with Perl | 08:46 |
| bialix | np | 08:46 |
| bialix | I'm already understand I'm unable to propely do this stuff | 08:46 |
| * bialix avoids do the things he can't test | 08:47 | |
| AfC | bialix: and, for what it's worth, that IS an in-production application, so it is a real example | 08:47 |
| AfC | bialix: even if it's a very tiny program | 08:47 |
| bialix | tiny? | 08:47 |
| AfC | bialix: the package is just a small program that tells you the time[zone] in various places: http://blogs.operationaldynamics.com/andrew/software/slashtime/slashtime-the-graphical-version.html | 08:48 |
| bialix | I understand | 08:48 |
| AfC | "tiny" :) | 08:49 |
| bialix | :-) | 08:49 |
| AfC | but "complete" in the sense that it installs properly, has translations, has a .desktop file, etc | 08:49 |
| AfC | The cafe I am sitting in is closing. See ya | 08:51 |
| * bialix waves | 08:51 | |
| * igc dinner | 09:30 | |
| poolie | hello again bialix | 09:43 |
| bialix | hello again poolie | 09:46 |
| bialix | poolie: I've tried to ask about including paramiko-default patch to 2.0 | 09:47 |
| poolie | hey | 09:47 |
| bialix | vila said you should judge | 09:47 |
| poolie | i just sent another post in the metronome thread | 09:47 |
| poolie | well, as you know, i think it's a good idea in general | 09:48 |
| poolie | if we're going to do it we should do it before 2.0beta | 09:49 |
| bialix | so we going to? | 09:50 |
| poolie | what's the worst that could happen? | 09:51 |
| poolie | :) | 09:51 |
| bialix | people continu asking why push to lp does not work on windows? | 09:52 |
| bialix | *continue | 09:53 |
| poolie | i guess if there are people who have complicated putty setups eg to set up proxies they might stop working | 09:54 |
| bialix | as I said BZR_SSH=plink force it | 09:55 |
| bialix | and this mentioned in NEWS in Compatibility break section | 09:55 |
| bialix | I'm aware about 3 cases when plink does not work with lp | 09:56 |
| poolie | mm | 09:56 |
| bialix | it seems it depends on actual plink/putty version | 09:57 |
| poolie | also, it would kind of avoid unnecessary variation | 09:57 |
| poolie | like if you have bzr working ok, and then for some other reason you install putty, it'll start doing something different | 09:58 |
| bialix | it? | 09:58 |
| poolie | it meaning this change | 09:58 |
| bialix | yes | 09:58 |
| vila | meh, where are the 1.18 and 2.0 branches on bazaar-vcs.org ? Or does the pqm direclty use the lp branches now ? | 09:58 |
| poolie | so being a bit more selfcontained is worthwhile | 09:58 |
| poolie | yes, direct to lp i think | 09:58 |
| poolie | ok, let's do it! | 09:59 |
| vila | poolie: so I send bialix patch to pqm against lp:bzr/2.0 ? | 10:00 |
| poolie | yes please | 10:00 |
| bialix | thanks gentlemen | 10:01 |
| poolie | just for future reference, i don't think this kind of fix would be appropriate to merge into the branch after the stable release | 10:01 |
| poolie | thanks for the patch bialix | 10:01 |
| bialix | it was easy | 10:01 |
| vila | wow, oh yes, lp:bzr/2.0 resolves to ~bzr-qm/bzr/2.0 .... cute :) | 10:01 |
| poolie | ok so i should probably go... | 10:02 |
| vila | poolie: need some help ? | 10:02 |
| vila | poolie: GO ! | 10:02 |
| poolie | ok, cheerio | 10:03 |
| vila | bialix: your started your branch from bzr.dev after 2.0 got created... | 10:04 |
| bialix | (and melody from crazy frog fly away...) | 10:04 |
| bialix | vila: ashes on my head! | 10:04 |
| poolie | https://edge.launchpad.net/bzr/+milestone/2.0 :) | 10:04 |
| bialix | vila: if you have rebase plugin installed, then cherrypicking will be easy | 10:08 |
| vila | bialix: no | 10:08 |
| vila | bialix: I mean, I don't have it installed | 10:09 |
| bialix | you want me to cherrypick it? | 10:09 |
| vila | yes please | 10:09 |
| bialix | k | 10:09 |
| bialix | lp:bzr/2.0 yes? | 10:09 |
| vila | bialix: yup | 10:10 |
| bialix | vila: your no applicable to both cases | 10:15 |
| vila | ? cherrry-pick is not easy ? | 10:16 |
| bialix | no, it's easy if you know how to run rebase :-P | 10:17 |
| bialix | jelmer should be proud of his weird design of -r argument for rebase command! | 10:17 |
| bialix | vila: rebased, and no conflicts encountered! | 10:18 |
| vila | pushed somewhere ? | 10:19 |
| bialix | vila: quick check: latest revision in 2.0 branch is luks patch? | 10:19 |
| bialix | vila: pushing now | 10:19 |
| vila | revno 4634 luks patch for branch --switch | 10:20 |
| bialix | vila: bzr+ssh://bazaar.launchpad.net/~bialix/bzr/win32-paramiko-default-2.0/ | 10:21 |
| bialix | pushed | 10:21 |
| vila | bialix: sent to pqm | 10:23 |
| bialix | thx | 10:23 |
| vila | I should certainly try to merge 2.0 to trunk sooner rather than later to catch the conflicts asap | 10:24 |
| vila | bialix: remind me to do that if I forget :D | 10:25 |
| bialix | tomorrow? | 10:25 |
| bialix | or after 2.0 is out? | 10:25 |
| vila | bialix: once it's landed in the 2.0 branch | 10:26 |
| bialix | hmmmmm | 10:26 |
| bialix | tomorrow then ;-) | 10:26 |
| vila | ok | 10:26 |
| vila | bialix: still there ? | 10:56 |
| bialix | yip | 11:00 |
| bialix | vila: what's up? | 11:00 |
| vila | ha, tortoisebzr now includes a wtcache.py file that uses the 'with' feature | 11:01 |
| vila | is 2.6 a strong requirement on windows now ? | 11:01 |
| vila | it makes the dev/dev installer build fails | 11:02 |
| bialix | wtcache? I think it's recent work from Naoki INADA | 11:02 |
| vila | yup | 11:02 |
| bialix | vila: no, it's wrong | 11:02 |
| bialix | he's asking about testing his new work | 11:02 |
| bialix | wait a sec | 11:03 |
| vila | this has landed on lp:tortoisebzr .... that's more than testing :) | 11:03 |
| bialix | vila: https://lists.launchpad.net/tortoisebzr-developers/msg00041.html | 11:03 |
| bialix | vila: lp:tbzr is open for everyone and Naoki the one who trying to maintain it | 11:04 |
| bialix | you should not be so grumpy | 11:04 |
| bialix | write him a mail, ok? | 11:04 |
| bialix | (preferrable using ML, but it's up to you) | 11:04 |
| vila | not grumpy ! (Damn, am I grumpy today ? Afc first now bialix, soon fullermd ? ) :-) :-/ | 11:04 |
| vila | bialix: just a heads-up, that's what the test farm is for :-D | 11:05 |
| bialix | vila: err! no! no! you're wonderfuil today | 11:05 |
| bialix | bad word chosen by me | 11:05 |
| bialix | sory | 11:05 |
| bialix | sorry | 11:05 |
| vila | if you can pass the info to INADA, that would be nice ! | 11:05 |
| vila | bialix: is he here ? | 11:06 |
| bialix | ok, so I'll answer him to tbzr ML. is ti what you want? | 11:06 |
| bialix | he? | 11:06 |
| vila | yes please, he asked for feedback, that's feedback :) | 11:06 |
| vila | INADA, is he here on IRC ? | 11:06 |
| bialix | his nick at lp: songofcandy | 11:07 |
| bialix | or something like that | 11:08 |
| bialix | I'm not sure he's chatting here | 11:08 |
| bialix | Japan timezone IIUC | 11:08 |
| bialix | vila: do you have precise traceback or error message? | 11:08 |
| vila | just a sec | 11:08 |
| vila | http://babune.ladeuil.net:26862/builders/installer-dev-plugin-dev/builds/35/steps/compile/logs/stdio | 11:09 |
| vila | look at the end | 11:09 |
| bialix | (cough) | 11:10 |
| bialix | is it URL stable? | 11:10 |
| vila | bialix: pretty stable yes | 11:11 |
| bialix | vila: error said it's not error but warning | 11:11 |
| vila | bialix: and it's read-only now | 11:11 |
| vila | SyntaxError: invalid syntax (wtcache.py, line 202) | 11:11 |
| vila | first the warning then an error, at least, that's how I read it | 11:12 |
| vila | bialix: the fix should a mere s/with/try+finally/ but without a way to test... | 11:13 |
| bialix | vila: http://pastebin.com/m75032c50 ok? | 11:14 |
| fullermd | vila: Hmmwhat? I have to be grumpy now? But I just got coffee... | 11:14 |
| vila | bialix: perfect | 11:14 |
| vila | fullermd: you don't have too, you have to say *I* am :) | 11:15 |
| vila | fullermd: you don't have too, you just have to say *I* am :) | 11:15 |
| fullermd | Oh. Well, that's why I had to get coffee, see. 'cuz you're so grumpy. And stuff. | 11:15 |
| bialix | lol | 11:15 |
| vila | hehe, and people think that because I work from home I can't have a good laugh.... | 11:16 |
| bialix | lol | 11:16 |
| AfC | I don't work from home. But I have a _really_ short commute from my home to my office. | 11:16 |
| fullermd | Heck, that's WHY you work from home. If you stare at a computer screen for hours, then bust out laughing in an office, people eventually put you in a straitjacket. | 11:16 |
| bialix | vila: thanks for head up, mail sent, waiting for songofacandy response | 11:17 |
| fullermd | I mean, so I hear. Not that I would ever be in a situation where I'd have such an experience. No siree Bob. That would be crazy. | 11:17 |
| vila | fullermd: indeed | 11:18 |
| bialix | fullermd: I do this all the time | 11:19 |
| bialix | in the office | 11:19 |
| AfC | fullermd: what's wrong with wearing a straitjacket in the office? | 11:19 |
| fullermd | AfC: It depends on who puts you in it :p | 11:19 |
| AfC | fullermd: and what colour it is. White is so passé | 11:20 |
| fullermd | Yah, Tie-dye is much more festive. | 11:20 |
| mrevell | Szilvester -- around? | 11:29 |
| mwhudson | mrevell: i think he's phanatic when he's here | 11:35 |
| mrevell | hey mwhudson, expanding your nick soon? Thanks, yeah, looks like he's not around. | 11:35 |
| mwhudson | mrevell: not sure about that, people give intellectronica enough grief for a long nick :) | 11:35 |
| * mwhudson zzz | 11:36 | |
| mrevell | :) | 11:36 |
| === JaredWigmore is now known as JaredW | ||
| bialix | vila: ping | 12:02 |
| bialix | vila: check mail, Naoki said he's fixed this issue, how hard is to test with your army of slaves? | 12:03 |
| quicksilver | it's the cost of the whips which really gets you down. | 12:05 |
| * bialix seems to lost his sense of humor today. too little coffee in the blood maybe | 12:10 | |
| vila | bialix: test launched, I'll keep you informed | 12:11 |
| bialix | cool | 12:12 |
| danigm | Hello, is there a hook to send mails at post-commit? like in subversion? I saw that exists bzr-email plugin but I want tu put in my server and not in every client | 12:25 |
| bialix | danigm: https://launchpad.net/bzr-hookless-email | 12:30 |
| danigm | bialix: ok, thanks | 12:31 |
| === mrevell is now known as mrevellunch | ||
| === abentley1 is now known as abentley | ||
| === abentley1 is now known as abentley | ||
| vila | bialix: test ok ! congrats to Naoki :) | 13:17 |
| vila | bialix: I was a bit long as I had to manually update the branch... I don't understand why, but that doesn't really matter for now | 13:17 |
| vila | test farm all green again :) | 13:18 |
| bialix | vila: how about publishing that installer as "nightly" build for testing? | 13:24 |
| vila | bialix: I have no idea of its quality *today*... but that's indeed the mid-term plan | 13:25 |
| bialix | well, Naoki asked for testing his changes | 13:25 |
| bialix | but it's almost impossible to do without any installer | 13:25 |
| bialix | even broken one | 13:25 |
| vila | AIUI jam uses the same script to build the official installers (using dev/release instead of dev/dev) | 13:25 |
| === mrevellunch is now known as mrevell | ||
| vila | abentley: BB down ? | 13:35 |
| === abentley1 is now known as abentley | ||
| vila | abentley: BB down ? | 13:58 |
| vila | abentley: not sure you got my first message | 13:58 |
| abentley | vila: restarted. | 14:08 |
| vila | abentley: thanks | 14:08 |
| jam | vila: I use release/release to build the official installers "make installer-all PYTHON=..." | 14:11 |
| vila | jam: yeah, right thanks for the heads-up :) | 14:12 |
| vila | jam: good morning :) | 14:12 |
| vila | jam: already get your first coffee ? :D | 14:13 |
| jam | vila: yep | 14:14 |
| === Noldorin_ is now known as Noldorin | ||
| === loxs_wrk is now known as loxs | ||
| bialix | vila/jam: so what about "nightly" builds for windows installer/tbz | 14:47 |
| bialix | tbzr? | 14:48 |
| vila | bialix, jam: I see two parts: 1) deciding whether the dev/dev installer is correctly built (jam ?), 2) Finding the right process to upload the installers to ... lp ? | 14:49 |
| vila | jam: for some context: the builds have been green for some days except this morning due to an update in tbzr, I raised the problem, bialix caught it, Naoki fixed it | 14:50 |
| vila | jam: a concrete example of the usefulness of the build farm :) | 14:51 |
| vila | jam: but now, bialix want more ! :-D | 14:51 |
| bialix | ... nad garyvdm would like to test it but asked for installer | 14:51 |
| bialix | *and | 14:51 |
| bialix | *rats | 14:51 |
| * bialix don't want more | 14:51 | |
| bialix | I've just threw idea | 14:52 |
| jam | so i think vila points out that we have daily builds | 14:52 |
| * vila rats forgot the BIG RED FLASHING JOKE :) | 14:52 | |
| jam | we just need to figure out where to put them | 14:52 |
| bialix | lp is not the good place | 14:52 |
| jam | lp seems like it would be an ok place | 14:53 |
| jam | given that the nightly-ppa is there | 14:53 |
| vila | I love the agreement :) | 14:53 |
| vila | bialix: why not a good place ? | 14:53 |
| jam | It isn't perfect, though | 14:54 |
| jam | as from what I can tell, downloads are release specific | 14:54 |
| jam | I suppose we could create a "windows-nightly" release target? | 14:54 |
| bialix | maybe to distinguish nightly it should be named something appropriate? | 14:54 |
| jam | I also don't know how we would prune out old downloads like they do with old ppa items | 14:55 |
| vila | err, aren't the nightly names already contain the trunk revno ? | 14:55 |
| bialix | vila: because it should be separate from official stables? | 14:55 |
| * pygi almost convinced libburnia folks (e.g. myself and some others) to move to bzr :p | 14:55 | |
| vila | bialix: ho, that's what the PPA are for, but may be the nightly PPA doesn't have the right kind of download space | 14:56 |
| vila | pygi: If you can't convince yourself.... :-D | 14:56 |
| bialix | PPA != download installers area? | 14:56 |
| bialix | pygi afraids of qbzr and garyvdm? | 14:56 |
| pygi | bialix, nah, one of the devs started with VCS back in the time we started with the project | 14:57 |
| pygi | and he doesn't understand all the benefits of bzr just yet (he uses it in a bad way) | 14:57 |
| pygi | (we use svn for most components atm, only use bzr for one) | 14:57 |
| bialix | VCS or VSS? | 14:57 |
| bialix | pygi: I'm bad in jokes today | 14:58 |
| pygi | I know | 14:58 |
| pygi | :P | 14:58 |
| bialix | :-P | 14:58 |
| pygi | vila, isn't that always the hardest? :) | 14:58 |
| vila | hmm, right, ~bzr-nightly-ppa is a team, not a project, it can have a PPA but not an upload area, AIUI | 14:58 |
| vila | pygi: depends.... ;) | 14:58 |
| pygi | vila, on cheese? | 14:59 |
| vila | pygi: hardest cheese ? | 15:01 |
| pygi | vila, no..I asked what does it depends on xD | 15:01 |
| vila | :) | 15:03 |
| jam | vila: I have a question for you. Did you see any of the conversation robert and I had about the 'sort_gc_optimal' stuff? | 15:18 |
| vila | on IRC ? | 15:19 |
| jam | yeah | 15:20 |
| jam | last night | 15:20 |
| jam | I can rehash the high points if you want | 15:20 |
| vila | I prefer :-) I was rather sleepy when I read that | 15:21 |
| vila | (yes, I was lurking :) | 15:21 |
| jam | so... topo_sort is non deterministic | 15:21 |
| jam | as it depends on sort order from dicts | 15:22 |
| jam | right now when we pack a repo | 15:22 |
| jam | we do "sort_gc_optimal" | 15:22 |
| jam | which is basically | 15:22 |
| jam | reversed(topo_sort()) | 15:22 |
| jam | so it is also non-deterministic | 15:23 |
| jam | We also have a concept that fetching between 2a repos should be "groupcompress" ordered. | 15:23 |
| jam | With the idea that streaming one to another can opportunistically repack a little bit | 15:23 |
| jam | The fundamental problem is that we 're-use' blocks when streaming from another repo | 15:23 |
| jam | so if you have a poorly packed repo | 15:23 |
| jam | and you stream it into another | 15:23 |
| jam | you end up with a poorly packed repo, that has only 1 pack file | 15:24 |
| jam | and thus autopack will never 'clean up' the new repo | 15:24 |
| jam | so we would *like* to have a way to opportunistically repack on the fly | 15:24 |
| jam | without having that degrade into repacking everything all the time | 15:24 |
| jam | one possibility | 15:24 |
| jam | if sort_gc_optimal was more stable | 15:24 |
| jam | was that you could compare the stream with the 'optimal' ordering | 15:24 |
| jam | and if it was close enough, re-use the incoming stream | 15:25 |
| jam | if it was different enough | 15:25 |
| jam | repack | 15:25 |
| vila | ha yes, my first reaction was: 1) make topo_sort deterministic, 2) switch to merge_sort order, | 15:25 |
| jam | because it is currently non-deterministic | 15:25 |
| jam | that doesn't really work | 15:25 |
| jam | so the problem is 'what is deterministic' :) | 15:25 |
| vila | hehe, hence 2) | 15:26 |
| jam | given a graph, you want to get identical results between repos | 15:26 |
| jam | which is a starting point | 15:26 |
| jam | the issue is that given 2 *similar but not identical* graphs, you want them to somehow be similar | 15:26 |
| poolie | hello jam, vila | 15:26 |
| jam | hi poolie | 15:26 |
| poolie | we overlap again | 15:26 |
| jam | poolie: yep. You're up way too late again :) | 15:26 |
| vila | how identical ? fully identical or identical enough ? :-} | 15:27 |
| jam | well the point is that if they are fully identical then you should get exact results | 15:27 |
| jam | that is mostly a given | 15:27 |
| jam | but often you will have 2 repos with slightly different revs | 15:28 |
| jam | and you want the sorting between them to be "stable" in a similar sense | 15:28 |
| vila | right, so merge_sort works where topo_sort fails | 15:28 |
| jam | sort of | 15:28 |
| jam | but merge_sort isn't all that stable either | 15:28 |
| vila | it isn't stable with ghosts only, and I'd argue that filing ghosts is a f. good occasion to recompress | 15:29 |
| jam | vila: let me give an example, just a sec | 15:31 |
| jam | http://paste.ubuntu.com/259307/ | 15:32 |
| jam | so if you consider that one side has graph F and the other G | 15:32 |
| poolie | jam, the only fixcommitted bug from spiv i see is https://bugs.edge.launchpad.net/bzr/+bug/402657 | 15:33 |
| ubottu | Launchpad bug 402657 in bzr "2a fetch over dumb transport reads one group at a time" [Critical,Fix committed] | 15:33 |
| poolie | which does have a branch attached but maybe not an mp | 15:33 |
| poolie | actually it does have https://code.edge.launchpad.net/~spiv/bzr/gc-batching/+merge/10643 | 15:33 |
| jam | it does | 15:33 |
| jam | I just didn't see it in my inbox for some reason | 15:33 |
| jam | I'll certainly review it | 15:33 |
| jam | argh... hopefully this is a MAD issue | 15:33 |
| jam | his MP has: ``bzr push`` locally on windows will no longer give a locking error with | 15:33 |
| jam | maybe he merged Robert's branch before it landed... | 15:34 |
| poolie | mm | 15:35 |
| poolie | probably out of sync | 15:35 |
| poolie | you could diff it again yourself | 15:35 |
| jam | yeah | 15:35 |
| spiv | jam: yeah, that would be a MAD issue I think :( | 15:35 |
| jam | just painful how many times we run into code review problems | 15:35 |
| jam | though I suppose we can now switch to having "bzr.dev" hosted on LP | 15:35 |
| jam | since we've had success doing that for the release branches | 15:36 |
| vila | jam: hmm, merge sort should be: A B|C D|E F or A B|C D|E G (same level nodes can be forced to respect an arbitrary but stable order (think revid alphanumerical)) | 15:36 |
| spiv | Launchpad could pay attention to the base_revision_id of merge directives and if it's not present in the target rescan before generating a diff. | 15:36 |
| jam | vila: I'm not sure that you understand merge-sort | 15:36 |
| spiv | Well, mirror then scan. | 15:36 |
| jam | it is "topological, with revisions appearing just before the rev that merged them" | 15:36 |
| spiv | (Although in this case I created the merge proposal via the web, so that wouldn't have helped...) | 15:37 |
| jam | spiv: supposedly it does something different if you send an MD attachment, rather than say "propose this branch" | 15:37 |
| vila | jam: I can see that, and I think it's a weakness as you just demonstrate :) | 15:37 |
| spiv | Anyway, it *is* late, and I'm off to sleep :) | 15:37 |
| jam | at least I've seen comments from Aaron that it re-uses the exact patch you sent | 15:37 |
| jam | spiv: sleep well | 15:37 |
| jam | vila: so while investigating, I also realized that the 'most stable' sort order may not be the best "compression" order. | 15:37 |
| jam | but I figured it would be good to talk about possibilities | 15:38 |
| jam | for example | 15:38 |
| vila | if you want stability you need leveling, | 15:38 |
| jam | sorted((gdfo, revision_id) for gdfo, revision_id in revisions) | 15:38 |
| jam | however | 15:38 |
| jam | for *best compression* order | 15:38 |
| jam | it is probably *not* good to group by gdfo | 15:38 |
| jam | as they *specifically* don't have ancestry in common | 15:38 |
| hsn | anybody knows if sf.net hosted trac supports bzr plugin? | 15:39 |
| jam | or they couldn't have the same gdfo | 15:39 |
| vila | correct | 15:39 |
| jam | certainly we would need to actually do real-world values to be sure | 15:39 |
| vila | I was about to say that merge_sort flatten the rev space but we want different ways to flatten | 15:39 |
| jam | but my gut says that gdfo would be more stable | 15:39 |
| poolie | hsn: i don't know, but given they support bzr it seems like a reasonable thing they should do | 15:39 |
| jam | but would be worse compression | 15:39 |
| jam | versus depth-first sort of sorting | 15:39 |
| vila | my guts agree with yours :) | 15:40 |
| jam | so right now I have an updated "gc_sort" which is topo_sort, but at each of the steps it sorts the parent_keys/child_keys | 15:40 |
| vila | i.e. A BD CE F ? | 15:41 |
| jam | though perhaps it is enough to just go via parent_keys | 15:41 |
| jam | since that is a stable ordering | 15:41 |
| jam | F D B E C A | 15:41 |
| jam | is the current order, I believe | 15:42 |
| vila | right, exactly what I said :-) (Believe it or not :) | 15:42 |
| jam | and the other would be | 15:42 |
| jam | G D B E C A | 15:42 |
| vila | and what if G has D as second parent ? | 15:42 |
| fullermd | G files a paternity suit, obviously. It plays out on national TV. Big scandal. | 15:43 |
| * vila puts his tie-dye suit back | 15:44 | |
| jam | vila: D *is* G's second parent | 15:44 |
| jam | the point is that it was sorted(parent_keys) | 15:44 |
| jam | D < E | 15:44 |
| vila | ok, that was unclear, | 15:44 |
| jam | so there is an open question of whether that is important | 15:44 |
| jam | if you don't have it | 15:45 |
| jam | then you get | 15:45 |
| vila | the question was: is it independent of the parent order | 15:45 |
| jam | F E C D B A | 15:45 |
| jam | G D B E C A | 15:45 |
| jam | well, depending on whether you walk right->left parent or left->right parent | 15:45 |
| jam | but walking left->right the 'right' gets put on the stack last, and thus gets popped off first | 15:46 |
| jam | probably we would want to walk left-parents first | 15:46 |
| jam | hmm.... | 15:46 |
| jam | I wonder if walking left parents first is more important than lexicographical order | 15:46 |
| vila | walking when ? | 15:46 |
| vila | oh, missed that line | 15:47 |
| vila | no, I don't get it, what walk, what stack ? | 15:47 |
| vila | when you create the group from the full texts ? You walk the graph ? | 15:48 |
| jam | vila: we sort the graph to figure out how we want to group the texts | 15:50 |
| jam | topo_sort uses a stack of nodes left to walk | 15:50 |
| jam | go to a node | 15:50 |
| jam | if parents are ready | 15:50 |
| jam | push them on to the stack | 15:50 |
| jam | pop from the stack to go to the next node | 15:50 |
| jam | there are other ways | 15:51 |
| jam | like everything in 'pending' is ready to be evaluated | 15:51 |
| jam | evaluate all pending nodes before evaluating their parents | 15:51 |
| jam | a bit more of a 'breadth-first' method | 15:51 |
| vila | oh, you're coding gc_sort ? | 15:51 |
| jam | similarly for the (gdfo, revision_id) sorted version | 15:51 |
| jam | vila: well, updating it. Given that we already have one based on topo_sort :) | 15:52 |
| jam | I don't really want to make topo_sort perfectly stable, because it gets to be *fast* | 15:52 |
| vila | ok, I missed that part of the context :) | 15:52 |
| vila | I think having a dedicated gc_sort is the way to go | 15:52 |
| jam | I agree :) | 15:54 |
| jam | I'm just trying to define the problem space well enough to decide on all the options for sorting an arbitrary graph :) | 15:54 |
| jam | for example, I *could* do merge_sort(sorted(tips)) | 15:55 |
| jam | and define merge-sort when there is more than one tip | 15:55 |
| jam | given that the algorithm is only defined for 1 tip | 15:55 |
| jam | of course, you can always have "special_tip => [tip1, tip2, tip3]" and filter special_tip back out at the end | 15:55 |
| cristi_an | hi,what is the diff between bzr checkout and bzr clone or branch | 15:56 |
| cristi_an | ? | 15:56 |
| vila | exactly and force or not an order on the tips | 15:56 |
| jam | cristi_an: in a bzr checkout when you do "bzr commit" it commits the change to the source branch, and then locally | 15:58 |
| jam | versus only committing locally, and you have to 'bzr push' the data back to the source | 15:58 |
| cristi_an | jam: and otherwise localluy | 15:58 |
| cristi_an | interesting and so diff from cvs and svn | 15:58 |
| jam | note that one of the main benefits is when you want to collaborate on a shared branch | 15:58 |
| jam | since it helps to keep the 2 parties in sync | 15:58 |
| jam | if one commits, the other has to update before they can commit | 15:59 |
| jam | often, it is desirable to work on your own local branches only to get things done before they are integrated | 15:59 |
| cristi_an | yep but the merge is done ok | 15:59 |
| cristi_an | alter ? | 15:59 |
| cristi_an | later | 15:59 |
| jam | however managing the *integration* branch is very well done via checkouts | 15:59 |
| cristi_an | jam: last sentece i did not fully understood | 16:00 |
| cristi_an | :( | 16:00 |
| jam | You have a project | 16:01 |
| jam | it will almost always have an integration branch of some sort | 16:01 |
| jam | (trunk, head, development focus, etc.) | 16:01 |
| cristi_an | trunk...yes | 16:01 |
| cristi_an | as in svn | 16:01 |
| jam | you do work on branches | 16:02 |
| cristi_an | that is more familiar to me | 16:02 |
| jam | but eventually that work is integrated into another branch | 16:02 |
| jam | (trunk) | 16:02 |
| cristi_an | correct ar some point | 16:02 |
| jam | if multiple people are committing to an integration branch | 16:02 |
| jam | a good way to collaborate | 16:02 |
| jam | is via 'bzr checkout' | 16:02 |
| jam | rather than having a local copy | 16:02 |
| cristi_an | that is ...a pian in the ass | 16:02 |
| jam | which may be out of date | 16:02 |
| jam | a bzr checkout requires you to be up-to-date before you can commit | 16:03 |
| cristi_an | that is more like svn cvs style | 16:03 |
| cristi_an | with checkout | 16:03 |
| jam | cristi_an: so you can still develop your feature in a branch. But then "cd trunk-checkout; bzr merge ../my-feature/branch; bzr commit -m "merging my feature"" | 16:03 |
| jam | checkouts in bzr are a way to bridge the gap between: | 16:04 |
| jam | I'm developing independently (distrbuted) | 16:04 |
| jam | I'm collaborating (centralized) | 16:04 |
| jam | Anything you can do with checkouts you can do with regular branches and a bit of care | 16:04 |
| jam | checkouts just help with the 'bit of care' part | 16:04 |
| cristi_an | i see | 16:05 |
| jam | vila: right | 16:05 |
| jam | the main problem with "force an order on the tips" | 16:05 |
| jam | is that any arbitrary new tip can upset the ordering | 16:05 |
| jam | if you sorted(tips) | 16:05 |
| jam | then if you have G F, and someone commits an "A" | 16:05 |
| jam | suddenly your whole graph gets rebalanced based on A | 16:05 |
| jam | since that is now the new sort tip | 16:06 |
| jam | of course, sorting somehow is better than not sorting at all | 16:06 |
| jam | vila: and this is now a bit circular. But it is the bits I'm trying to understand as I come up with the graph => order of texts in groups algorithm | 16:06 |
| vila | right, it should only occur at the "tip[s]" of the graph so, only for the last inserted revisions | 16:06 |
| jam | vila: well, most algorithms are dependent on the starting point | 16:07 |
| jam | merge_sort and topo_sort both obviously being effectde | 16:07 |
| jam | effected | 16:07 |
| jam | affected... actually | 16:07 |
| jam | (i think, I'm really bad about that one) | 16:07 |
| vila | one question then, we're talking about file graphs here right ? How many revisions can you put into a group ? | 16:07 |
| jam | vila: as many as will fit | 16:07 |
| jam | yes it is a bit loose | 16:07 |
| jam | the current rule is: | 16:08 |
| jam | fit up to 2MB worth of mixed-file-id data, or 4MB of single file-id data | 16:08 |
| vila | but inside a single pack right, until the next autopack that is | 16:08 |
| jam | or 2x the size of the largest content, if it is >4MB | 16:08 |
| vila | ? | 16:08 |
| jam | vila: well, we don't split groups between packs (yet, if ever) | 16:08 |
| cristi_an | jam i reviewd out discussion | 16:08 |
| cristi_an | jam: thx much more clear now | 16:09 |
| vila | My point is that inside a pack you don't insert so your graph is immutable | 16:09 |
| jam | cristi_an: happy to help | 16:09 |
| jam | vila: sure, but when you transmit those to another repo... | 16:09 |
| jam | or during pack | 16:09 |
| jam | etc | 16:09 |
| jam | My "big picture" work is opportunistically repacking groups | 16:09 |
| jam | during transmission | 16:09 |
| jam | and the "little picture" is that we need a stable way of listing content, so that the opportunistic repacker doesn't flip-flop all the time | 16:10 |
| vila | but even in that context you know the full graph you care about no ? | 16:10 |
| jam | thinking that things should be group A B C then C B A then BCA then... | 16:10 |
| cristi_an | how can i update a branch ? | 16:10 |
| cristi_an | since a checkout is bzr update | 16:10 |
| jam | cristi_an: a regular branch is usually "bzr pull" a checkout is usually "bzr update" | 16:10 |
| cristi_an | same as for checkout ? | 16:11 |
| vila | could you really receive disconnected parts of a graph, starting a group and then receive connecting parts while still using the same group ? | 16:11 |
| cristi_an | i mean for a project that was get usign checkout ? | 16:11 |
| jam | vila: well, if you consider a streaming interface, yes | 16:11 |
| vila | ha ! | 16:11 |
| jam | you would get C => [A B], A => [], B => [A] | 16:12 |
| cristi_an | jam | 16:12 |
| cristi_an | thx | 16:12 |
| jam | however, that isn't particularly of concern | 16:12 |
| jam | well maybe some | 16:12 |
| jam | get_record_stream() determines the order to send data | 16:12 |
| vila | jam: I would tend to punt during the transfer waiting for the next autopack to get it right, is that acceptable ? | 16:12 |
| jam | but insert_record_stream() is responsible for putting that data into the target repo, and possibly rebuilding groups | 16:13 |
| jam | vila: we have determined that it is not | 16:13 |
| vila | if the sending order can acted upon then... surely that's better | 16:13 |
| jam | specifically | 16:13 |
| jam | if my source repo has 1 large pack, and 200 loose packs | 16:13 |
| jam | and I fetch from that | 16:13 |
| jam | the data stream will create 1 large pack | 16:13 |
| jam | with lots of loose data inside | 16:13 |
| jam | and then my target repository | 16:13 |
| jam | will have a single large pack | 16:13 |
| jam | that will never get repacked | 16:13 |
| jam | Too big to fail.... :) | 16:14 |
| vila | don't do it then :) | 16:14 |
| vila | create several smaller packs | 16:14 |
| jam | vila: how do we know what to put where? | 16:14 |
| jam | what heuristic do we use that we are ready to start a new pack | 16:14 |
| jam | at the moment, what I'm thinking | 16:15 |
| vila | size | 16:15 |
| jam | is to have insert_record_stream() keep a "pending group" open | 16:15 |
| jam | and if it gets a record that it thinks needs repacking | 16:15 |
| jam | to put it into the pending group | 16:15 |
| jam | with the algorithm there being | 16:15 |
| jam | a Group with 1 entry | 16:15 |
| jam | (at the moment) | 16:15 |
| jam | and then fetch requests things in 'groupcompress' order | 16:15 |
| jam | so if things are out-of-order they will get repacked on the fly | 16:15 |
| jam | as we will split up the old group if it doesn't yield data in the correct order automatically | 16:16 |
| jam | I'm not sure if you understand that from just what I've written. But it makes sense in my head... | 16:16 |
| vila | trying to rephrase: you have a way to detect that you're creating a bad group and trigger its reconstruction afterwards ? | 16:17 |
| jam | vila: mmm... | 16:17 |
| jam | the source is already split up into groups | 16:17 |
| jam | if we request "unordered" we get the groups as they exist | 16:17 |
| jam | if we make a request for "topological" or "groupcompress" ordered | 16:18 |
| jam | then the source will send groups that match the requested ordering | 16:18 |
| jam | but will create new groups if it needs to | 16:18 |
| jam | or truncate existing groups, etc. | 16:18 |
| jam | at the moment | 16:18 |
| jam | we have bug #402645 | 16:19 |
| ubottu | Launchpad bug 402645 in bzr "fetch for --2a formats seems to be fragmenting" [Critical,In progress] https://launchpad.net/bugs/402645 | 16:19 |
| jam | which is that we make a groupcompress request | 16:19 |
| vila | so why not use unordered ? It seems to guarantee that the groups are not that bad and can be made better at the next repack | 16:19 |
| jam | which causes the source to create small group fragments | 16:19 |
| jam | vila: see above as for "at next repack" | 16:19 |
| jam | after initial fetch | 16:19 |
| jam | "next repack" never happens | 16:19 |
| vila | but if the groups are correct that's not a problem | 16:20 |
| jam | well, for the data transmitted with the initial fetch, it will never be repacked via autopack | 16:20 |
| jam | vila: but they aren't in a real world repo | 16:20 |
| jam | which has some amount of "perfect" groups | 16:20 |
| === Noldorin_ is now known as Noldorin | ||
| jam | and then a whole lot of new "not yet autopacked" groups | 16:20 |
| jam | and probably some "autopacked, but not with all the new stuff yet" | 16:20 |
| jam | given that our "optimal packing" is newest first | 16:20 |
| jam | we can never be truly optimal in a live repo | 16:20 |
| jam | since there will always be a bit more new stuff | 16:20 |
| vila | hmmm | 16:21 |
| jam | so the other bug is bug #402652 | 16:21 |
| ubottu | Launchpad bug 402652 in bzr "smart fetch for --2a does not opportunistically combine groups" [High,Triaged] https://launchpad.net/bugs/402652 | 16:21 |
| jam | the twin to #402645 | 16:21 |
| vila | I'm back to the idea that we should create several packs | 16:21 |
| jam | namely, if we are going to fragment, then we should recombine | 16:21 |
| jam | vila: that is a possibility | 16:21 |
| jam | but how do we know what/when/where to do that? | 16:21 |
| jam | remember that individual packs are meant to be fairly self-contained | 16:22 |
| jam | though I guess not fully self contained | 16:22 |
| jam | given that a pack with rev 10 won't have the text files for rev 9 | 16:22 |
| jam | well, from rev 9 that are still present in rev10 | 16:22 |
| vila | where is the easiest: only locally do you have the right info to do a good job, the knowledge can't be shared | 16:22 |
| vila | when: repack, repack, repack | 16:23 |
| jam | vila: so I already have a patch for review for bug #402645 | 16:23 |
| ubottu | Launchpad bug 402645 in bzr "fetch for --2a formats seems to be fragmenting" [Critical,In progress] https://launchpad.net/bugs/402645 | 16:23 |
| jam | which would be nice to get reviewed | 16:23 |
| vila | that could not be simpler that handled at repack time | 16:23 |
| jam | I think lifeless was so-so on it, but I don't think he was blocking | 16:23 |
| vila | that left what... and that one is not easy :D | 16:24 |
| jam | vila: so... the problem with 'repack' time, is that for very large projects repacking everything takes a while | 16:24 |
| jam | it would be nice to have a lighter repack | 16:24 |
| jam | which is what we have autopack for today | 16:24 |
| jam | but that assumes that a single pack file is already as optimally packed as it could be | 16:24 |
| jam | one option | 16:24 |
| vila | yeah, I mean autopack, sorry, the point where you decided to group the last 10 packs | 16:25 |
| jam | is that we get the pack code to produce deterministic output | 16:25 |
| jam | such that we compare what a pack actually contains | 16:25 |
| jam | with what the optimizer would create | 16:25 |
| vila | wait ! | 16:25 |
| jam | and if they differ, redo the work | 16:25 |
| vila | you just pointed out the flaw ! | 16:25 |
| vila | we assume that a single pack file is already optimally packed | 16:25 |
| vila | that's wrong and we know when | 16:26 |
| vila | so how about repacking that one when we know it's wrong ? Is it already too late ? | 16:26 |
| vila | repacking with a special sense here: don't try to combine with others, focus on that one | 16:26 |
| vila | or not... | 16:26 |
| jam | vila: how do we know when? | 16:27 |
| vila | didn't you say you can identify that a group badly compressed ? | 16:27 |
| jam | (its a serious question, how do we detect that a pack is sub-optimal without fully repacking) | 16:27 |
| jam | vila: I'm saying maybe we can | 16:27 |
| jam | potentially by checking the sort order | 16:28 |
| jam | though that requires.... | 16:28 |
| jam | a deterministic sort order | 16:28 |
| jam | which ... is where I started this discussion :) | 16:28 |
| vila | gc_sort is deterministic, we agreeD on that :) | 16:28 |
| jam | it is not | 16:28 |
| jam | it potentially is | 16:28 |
| vila | it should | 16:28 |
| jam | so here is the next issue with determinism, and why it would be good to be stable when changing graph | 16:29 |
| jam | consider | 16:29 |
| jam | A B C D E F G | 16:29 |
| vila | and locally you can even realize that you're receiving a group that will be better compressed here but the other side couldn't know | 16:29 |
| jam | which are currently in groups of: | 16:29 |
| jam | [G F E] [D C B A] | 16:29 |
| jam | it would be good that when adding H | 16:29 |
| jam | we don't end up with | 16:29 |
| jam | [H G F] [E D C] [B A] | 16:29 |
| jam | If instead we could get | 16:29 |
| jam | [H G F E] [D C B A] | 16:30 |
| jam | that would mean that our 'lite-repack' doesn't have to touch everything | 16:30 |
| jam | just a group here and there that we push some extra data into | 16:30 |
| jam | vila: you can, but if you aren't going to look beyond the current pack file, you actually have *less* data... | 16:30 |
| vila | one question: is it legal to create groups in new packs from bits of groups in old packs ? | 16:30 |
| jam | it is legal to have multiple copies of a text in different packs | 16:31 |
| jam | Is that sufficient for your question? | 16:31 |
| vila | right | 16:31 |
| jam | of course, having 2 copies of a text in your repository is, by definition, sub optimal :) | 16:32 |
| vila | so we can create a new pack with only well compressed groups and wait for the autopack to clean the dust | 16:32 |
| vila | of force the cleaning | 16:32 |
| jam | vila: so I think you are saying that Repository.start_write_group() should be creating 2 pack files | 16:32 |
| jam | one with 'seems to be good' data | 16:32 |
| jam | and one with 'seems to need repacking' data | 16:33 |
| jam | though again, if you are only creating 2 packs... | 16:33 |
| jam | autopack doesn't kick in for a while | 16:33 |
| vila | but you force it with a focus on the need repacking one | 16:33 |
| vila | what worries me is that we may still transfer too much data... | 16:34 |
| jam | vila: well, there are other problems. Like the fact that 'optimally' you would probably want to mix some of the data in the 'needs repacking' pack with the data in the 'fully packed' pack | 16:35 |
| vila | nahhh, what is the risk that a group contains irrelevant data for a given fetch ? Isn't it capped by your 2M limit anyway ? Or can that trigger multiple times for a single fetch | 16:35 |
| jam | Consider a group of a single file content | 16:35 |
| jam | which has 100 revs of that content, and you get a single 'ungrouped' text of the same file | 16:36 |
| jam | vila: so the server side code knows that you are requesting XX bytes out of the 2M group, and can opportunistically split up a group | 16:36 |
| jam | which is currently causing our fragmentation issues :) | 16:36 |
| vila | Is it a bug that it split too much or is needed for some reason ? | 16:37 |
| jam | the bug is that our current fetch says: | 16:39 |
| jam | give me the first 2 texts from group A, and the first 2 texts from group B, then the middle 3 texts from A, then middle 3 from B, then the last 2 from A, and last 2 from B | 16:40 |
| jam | which causes a nice 7 entry group A and 7-entry B to be split up | 16:40 |
| jam | into 6 groups 2, 2, 3, 3, 2, 2 | 16:40 |
| jam | the *good* is that we don't send the full 14 texts multiple times | 16:40 |
| jam | the bad is we end up fragmenting without recombining afterwards | 16:40 |
| jam | The original idea we had for smart fetch was bug #402652 | 16:41 |
| ubottu | Launchpad bug 402652 in bzr "smart fetch for --2a does not opportunistically combine groups" [High,Triaged] https://launchpad.net/bugs/402652 | 16:41 |
| jam | we could create optimal groups on the fly | 16:41 |
| jam | (whether that ends up being done in the server or the client...) | 16:41 |
| vila | I vote for the client... half-heartedly :-/ | 16:42 |
| jam | vila: in theory client scales better, because you have 1 server and N clients | 16:42 |
| vila | It's the fetch for the smart server or also for dumb ones ? | 16:43 |
| jam | that said, because of 'push vs pull vs copy ' who the client is ... | 16:43 |
| jam | (it can be the source or target, or neither as an intermediary) | 16:43 |
| jam | vila: so it is basically the same fetch, it just depends on the layering | 16:43 |
| jam | "smart fetch" is | 16:43 |
| jam | dumb_fetch => SmartObject => bytes on the wire => RemoteRepository => local repo | 16:44 |
| jam | versus | 16:44 |
| jam | dumb_fetch => local_repo :) | 16:44 |
| jam | So for plain 'http' requests, we have to read the whole group | 16:45 |
| jam | and then locally we split it up into smaller bits | 16:45 |
| jam | we have a local cache of groups | 16:45 |
| jam | so we are unlikely to fetch the same big group twice | 16:45 |
| jam | though it is possible that we do so if we are really bad about our fetch ordering | 16:45 |
| vila | 1) we shouldn't "fragmenting without recombining" or at least we should give hints about it so that the other side knows there is work to do, | 16:50 |
| vila | 2) if the "smart" is to send multiple groups to reduce the amount of data transmitted and we fail to achieve that, that's not smart :-/ | 16:52 |
| jam | vila: I'm pretty sure (2) is working | 16:56 |
| jam | with the caveat that it is introducing (1) :) | 16:56 |
| vila | so if we are happy with 2, the only problem is to not consider the received pack as optimally compressed no ? | 16:57 |
| vila | What if you just look at that pack file, counting groups/file and deciding if it's worth keeping or not ? | 16:58 |
| vila | Kind of an autopack after fetch focused on the just received pack ? | 16:59 |
| === deryck is now known as deryck[lunch] | ||
| vila | You can even spawn it in the background :-) | 17:00 |
| * kfogel is away: lunch + an errand | 17:12 | |
| oubiwann | lifeless: hey man, I fixed that branch and re-submitted the review | 17:26 |
| jam | oubiwann: just so you know, lifeless is usually sleeping for another 4hrs or so | 17:31 |
| oubiwann | jam: yeah, that's what I figured... | 17:31 |
| oubiwann | jam: I msg'ed him in the off chance that he checks his irc highlights ;-) | 17:31 |
| jam | it does | 17:32 |
| === deryck[lunch] is now known as deryck | ||
| === beuno is now known as beuno-afk | ||
| vila | pfffffffff | 18:02 |
| vila | jam: ping | 18:03 |
| jam | vila: ? | 18:03 |
| vila | jam: I just upload new packages for bzr-gtk in bzr-beta-ppa | 18:03 |
| vila | When should I do the same for bzr-ppa at the latest for 1.18 ? | 18:04 |
| vila | well, doesn't reallt matter I suspect | 18:04 |
| jam | I think you should copy them from the beta ppa | 18:04 |
| vila | well, now that the script is written... :-) | 18:05 |
| garyvdm | Hi vila, jam | 18:05 |
| vila | hi garyvdm , too bad, I'm about to leave :-) | 18:06 |
| garyvdm | np - just saying hi. | 18:06 |
| garyvdm | Hi bialix | 18:06 |
| bialix | Hi garyvdm! | 18:06 |
| vila | I've seen your blueprint for the conflict manager, nice job, I'll try to comment if I find the time before you code it :-D | 18:06 |
| bialix | garyvdm: have some quick questions | 18:07 |
| bialix | may I? | 18:07 |
| garyvdm | sure | 18:07 |
| bialix | garyvdm: you can answer in short form | 18:07 |
| garyvdm | vila: There lots more that I still have in my head. | 18:07 |
| vila | james_w: builddeb rocks, just wanted to let you know :) | 18:07 |
| vila | james_w: bzr-builddeb I meant ! | 18:08 |
| james_w | thanks :-) | 18:08 |
| bialix | garyvdm: 1) your fix for qdiff and painting is great. is it possible to do similar thing for annotate? today annotate is slow on scrolling... | 18:08 |
| bialix | james_w: hi, great idea around bzr-build | 18:08 |
| vila | garyvdm: as all of us :) The tricky thing is to get them out :) | 18:08 |
| bialix | james_w: at first I've thought you steal my scmproj cookies :-) | 18:09 |
| garyvdm | bialix: annotate is slow to scroll because it's only loading revision on screen, like qlog. | 18:09 |
| bialix | james_w: sorry: bzr-builder of course | 18:09 |
| bialix | garyvdm: and so? | 18:10 |
| garyvdm | bialix: I plan to make both qlog and qannotate be a bit more aggressive with revision loading. | 18:10 |
| garyvdm | bialix: Its the same bit of code. | 18:10 |
| bialix | garyvdm: that's great, especially if you put this agression inth thread ;-) | 18:10 |
| garyvdm | :-o | 18:10 |
| bialix | ok, ok | 18:10 |
| bialix | oh, ok | 18:10 |
| james_w | bialix: yeah, it is quite similar to scmproj :-) | 18:10 |
| bialix | james_w: but it's much more than that in one area and much less than that in other | 18:11 |
| bialix | ;-) | 18:11 |
| bialix | but I like the idea | 18:11 |
| james_w | heh | 18:11 |
| bialix | maybe I can persuade guys like jam to use it for working with windows installer configuration | 18:11 |
| bialix | garyvdm: 2nd q: oh, you already answer it about agressive loading | 18:13 |
| bialix | garyvdm: maybe I'll put some my thoughts about threads/subprocesses and multipass work as text document? (not wiki :-P) and we can work on it toghether? | 18:14 |
| bialix | garyvdm: 3rd) can we put throbber as status bar? | 18:14 |
| bialix | something like in firefox | 18:14 |
| bialix | (and other browsers) | 18:14 |
| garyvdm | bialix: If you want to look at the qlog/qannotate revisions loading, the code is in lib/revtreeview.py | 18:15 |
| garyvdm | bialix: You can put the throbber anywhere, so it is a question of design. | 18:15 |
| bialix | mostly I'm not very like as it appears and disappears | 18:15 |
| garyvdm | The throbber will look funny just bellow the buttons. | 18:16 |
| garyvdm | Or where you thinking above the buttons? | 18:16 |
| bialix | well, if it will be status bar, then we have to use progress bar instead of spinning wheel | 18:16 |
| bialix | no, I mean status bar, like in firefox | 18:16 |
| bialix | wannan screenshot? | 18:17 |
| garyvdm | Don't worry. I know what you mean | 18:17 |
| bialix | ok | 18:17 |
| bialix | garyvdm: igc is not asked you about packaging bzr-explorer? | 18:18 |
| garyvdm | bialix: maybe just have a throbber that sits in the top right, with no text like firefox... | 18:18 |
| garyvdm | No | 18:18 |
| bialix | top right? under title bar icon/buttons? | 18:19 |
| garyvdm | bialix: My knowledge about debian packaging in limited to "How to update qbzr's packages." | 18:19 |
| garyvdm | bialix: I'll have a shot on the weekend. | 18:20 |
| bialix | new firefox (at least on windows) lacks this spinning wheel at top right, but I remember it | 18:20 |
| bialix | "How to update qbzr's packages." -- that's cool anyway | 18:20 |
| garyvdm | I did not even notice that the top right throbber had gone... | 18:21 |
| bialix | garyvdm: I've just asked. igc want bzr-explorer 0.7 into karmic | 18:21 |
| bialix | (I'm about of packaging 0.7 release now) | 18:21 |
| garyvdm | bialix: 0.7 - I just read on the ml about 0.8? | 18:22 |
| bialix | bzr-explorer 0.7 is not released yet | 18:23 |
| bialix | tonight wil be | 18:23 |
| garyvdm | Oh - worry - miss read | 18:23 |
| garyvdm | *sorry | 18:23 |
| bialix | np | 18:23 |
| bialix | garyvdm: also I want to redesign qbzr.conf. completelly | 18:23 |
| jam | a | 18:24 |
| bialix | I'm thinking about this many months | 18:24 |
| bialix | jam: ? | 18:24 |
| jam | sorry, wrong window | 18:24 |
| garyvdm | bialix: I would recommend that you try find someone else to do the packaging, cause I will be very slow. Maybe luks? | 18:24 |
| bialix | garyvdm: don;t worry about packaging, I'm sure Ian will find the way | 18:25 |
| bialix | I was unsure is he asking you or not | 18:25 |
| garyvdm | bialix: To be honest, I'm not to familiar with the .conf code. You know it much better. | 18:26 |
| bialix | garyvdm: about qbzr.conf: I want to put data in more sections and subsections. instead of keep everything in [DEFAULT]. If you have any thoughts on this topic we can discuss it. otherwise I'm planning to work on it soon | 18:26 |
| bialix | ah, ok | 18:26 |
| bialix | I'm still unsure ow to organize things like geometry settings, color settings | 18:27 |
| bialix | s/ow/how/ | 18:27 |
| garyvdm | Yes - It would be nice if the the window sizes were separate from every thing else. | 18:27 |
| bialix | and I want some universal MRU handling (latest 10 pull locations used, push, commit messages etc) | 18:28 |
| bialix | garyvdm: precisely. | 18:28 |
| bialix | it was my first intent | 18:28 |
| * bialix often mulling some ideas several weeks/months because there is always bugs to fix rather than redesign deep internal code | 18:29 | |
| bialix | garyvdm: also I want to redesign most of qsubprocess windows: to always show working branch/tree location. | 18:29 |
| garyvdm | Yes | 18:30 |
| garyvdm | Like qcommit | 18:30 |
| bialix | I found it's very easy to lost identity while working with multiple branches in bzr-explorer | 18:30 |
| bialix | yep, but maybe a bit shorter | 18:30 |
| bialix | garyvdm: and perhaps latest. today I've asked about qrevert to revision | 18:31 |
| bialix | I'm not filed a bug report yet | 18:31 |
| bialix | trying to understand where to put this control | 18:32 |
| garyvdm | bialix: I have the same thing. I've been thinking about this for about this for about a year now: http://bazaar-vcs.org/qbzr/Blueprint/diffmerge | 18:32 |
| garyvdm | Note that blueprint is not finished... | 18:32 |
| bialix | we have several dialogs where we expecting user can specify revision | 18:33 |
| garyvdm | Lots still in my head. | 18:33 |
| bialix | garyvdm: I like your screenshots | 18:33 |
| bialix | very much | 18:33 |
| bialix | very impressive | 18:33 |
| bialix | it seems meld's way is too complicated (from screenshots) | 18:33 |
| bialix | so, garyvdm, what we can do about revision selector? ;-) | 18:34 |
| garyvdm | Screenshots made with balsamiq | 18:34 |
| garyvdm | bialix: Yes I need to finish that. | 18:34 |
| bialix | I remember you stumbled upon some bugs/issues with qt | 18:35 |
| garyvdm | igc wants me to make it do all different types of revision selectors. | 18:35 |
| bialix | I'm still thinking about reusing qlog widget | 18:35 |
| garyvdm | Yhea - had problems putting qlog inside a qcombobox | 18:36 |
| bialix | is it possible to run separate dialog with qlog-like graph and allow user to click/dbl-click on revision and we pick it? | 18:36 |
| garyvdm | That would be easy | 18:36 |
| bialix | for selecting range -- just draw the mouse with button pressed and all | 18:37 |
| bialix | or something like that | 18:37 |
| bialix | something easy | 18:37 |
| garyvdm | bialix: I'm busy trying to use jam's new graph code to make qlog faster. | 18:38 |
| garyvdm | It's promising. | 18:39 |
| bialix | garyvdm: I'd like to fix https://bugs.launchpad.net/qbzr/+bug/417895 | 18:39 |
| ubottu | Launchpad bug 417895 in qbzr "qannotate error when clicking on line which origin is dotted revno" [Critical,Confirmed] | 18:39 |
| bialix | if you will have a time to comment on it, I'll try to find the root of problem | 18:39 |
| jam | garyvdm: btw, feedback is welcome if you find "it would be nicer if..." | 18:39 |
| bialix | he, faster :-( | 18:39 |
| bialix | heh | 18:40 |
| bialix | today qlog on bzr.dev opens for me ~10 seconds | 18:40 |
| garyvdm | jam: sure, I've allready got a draft mail :-) | 18:40 |
| garyvdm | bialix: I want that to be 1sec... | 18:41 |
| bialix | I will be happy if it start painting latest revno from the start and then loading the tail later | 18:41 |
| jam | hmm... cold cache it is 18s here, 12s before the window shows | 18:41 |
| jam | hot, 5s | 18:42 |
| bialix | (and working in thread because it's completely ignore repaint while doing loading) | 18:42 |
| garyvdm | Speed is important for using it for a revision selector | 18:42 |
| bialix | I think we have to load only mainline first | 18:42 |
| garyvdm | It takes about 45 sec for OOo | 18:42 |
| garyvdm | yes | 18:42 |
| bialix | because for revision selector this is what you need 90% of the time | 18:42 |
| jam | well, for OOo, *everything* is mainline... | 18:43 |
| bialix | oh, I recall | 18:43 |
| bialix | garyvdm: qlog on multiple branches | 18:43 |
| bialix | garyvdm: can we dont show dotted revnos for non-trunk branches? | 18:43 |
| * garyvdm hides under the desk. | 18:43 | |
| bialix | no, it's easy question | 18:44 |
| garyvdm | or the right revno... | 18:44 |
| bialix | right mainline revno would be confusing | 18:44 |
| bialix | but dotted revno is unusable | 18:44 |
| bialix | I can't merge using this revno | 18:44 |
| garyvdm | Easy to not show the wrong revno | 18:45 |
| bialix | I'll be happy just to see no revno at all | 18:45 |
| * bialix has too much questions/ideas so not everything is filed as bugs | 18:45 | |
| garyvdm | :-) | 18:46 |
| bialix | garyvdm: it was last question. I promise! | 18:47 |
| garyvdm | jam: for OOo, I think we have to look at loading just part of the mainline... | 18:47 |
| garyvdm | Sure | 18:47 |
| * bialix packaging 0.7 now | 18:47 | |
| bialix | oh | 18:48 |
| bialix | and after rebase qlog refresh crashed... | 18:48 |
| jam | garyvdm: so... qlog could just load enough of the mainline to fill the first screen | 18:48 |
| * bialix hides | 18:48 | |
| jam | and read those revisions so that it could put up summary messages | 18:48 |
| jam | and then spawn something that would load the rest of the data | 18:48 |
| garyvdm | Jam: yes | 18:48 |
| jam | you can number mainline revs, etc | 18:48 |
| jam | without needing the full graph | 18:48 |
| garyvdm | bialix: please log a bug. | 18:49 |
| jam | arguably, we could have something inbetween 'get_parent_map()' and 'get_known_graph_ancestry()', I'm just not sure exactly how to flesh that out | 18:49 |
| jam | so I didn't bother yet | 18:49 |
| jam | (give me as much parent information as you can cheaply determine from these tips) | 18:49 |
| jam | note also that if something like OOo switches, they will likely have a better conversion that actually makes use of their metadata in cvs to do merges | 18:50 |
| jam | I'm not positive of that | 18:50 |
| jam | but they have 3rd party tools to do a lot of merging, etc. for them | 18:50 |
| jam | built on top of cvs | 18:50 |
| jam | so there is some merge info there if people chose to extract it | 18:50 |
| garyvdm | I need to get a copy of a OOo branch... | 18:50 |
| jam | ping igc, he uploaded it somewhere | 18:51 |
| jam | let me check | 18:51 |
| bialix | does mysql branch is also very heavy and have much merge info? | 18:51 |
| jam | bialix: mysql is *very* bushy | 18:51 |
| garyvdm | bialix: Yes - I do have copy of that. | 18:51 |
| jam | something like 65k ancestry revs, versus... 3k mainline? | 18:51 |
| bialix | bushy? hmmm | 18:51 |
| * bialix wonder what fullermd would say about this | 18:52 | |
| garyvdm | jam: Aprox how many mb is OOo branch. I have limited bandwidth. | 18:52 |
| bialix | gigs? | 18:52 |
| jam | yeah | 18:52 |
| jam | checking | 18:53 |
| jam | 1.3GB in tar.bz2 form | 18:53 |
| jam | 945MB in .bzr/ | 18:53 |
| * bialix wonder when people start using torrents to get such big repos | 18:53 | |
| jam | bialix: there already is gittorrent, IIRC | 18:53 |
| bialix | cool | 18:53 |
| jam | garyvdm: 3.0GB of .bzr/ + working tree | 18:54 |
| bialix | wow | 18:54 |
| jam | garyvdm: http://people.canonical.com/~ianc/benchmarks/repos/bzr/ | 18:54 |
| jam | that has, emacs, OOo, python, mozilla, etc. | 18:55 |
| bialix | interesting how big lp sources? | 18:55 |
| garyvdm | Cool | 18:55 |
| bialix | comparing to those | 18:55 |
| jam | bialix: about 100-200MB, IIRC | 18:55 |
| jam | (note that numbers quoted are for --2a formats... LP was 1.2GB in --pack-0.92) | 18:56 |
| jam | MySQL is 600MB in --pack-0.92, around 225MB in --2a, IIRC | 18:56 |
| bialix | jam: because bzr is also used packs as repo format it's possible to build bzrtorrent, hm? | 18:56 |
| garyvdm | jam: I think I'm going to ask igc to post me a flash drive with some repos on. It will be cheaper that way :-( | 18:56 |
| * pgega is away: I'm busy | 18:56 | |
| jam | bialix: well, I think it is based on git's sha1 content stuff. But certainly we *could* do a torrent-like protocol. I thought someone brought it up on the mailing list a while back | 18:57 |
| jam | garyvdm: where do you live? | 18:57 |
| garyvdm | South Africa | 18:57 |
| bialix | jam: yeah sha-1 hashes should helps them | 18:57 |
| garyvdm | Someone worked out that if you wanted to download more than 5gib in south africa, it's quicker to fly to hong kong, download it there, and fly back... | 18:59 |
| jam | we have sha1 hashes, but things are addressed in that sense | 18:59 |
| jam | garyvdm: well, there is the old 'lorry full of backup tapes' question | 18:59 |
| bialix | btw jam, how's hard to implement commit --amend? is it possible to avoid uncommit/commit dance to simply fix commit message? | 18:59 |
| jam | at what point is a truck full of backup tapes higher bandwidth than OC-3 ? | 18:59 |
| * pgega is back (gone 00:03:15) | 19:00 | |
| jam | bialix: The hardest pressure would be to get it past review | 19:00 |
| jam | I don't see the specific benefit over uncommit/commit myself. | 19:00 |
| jam | given that as I understand it | 19:00 |
| jam | commit --ammend == uncommit + commit | 19:00 |
| bialix | use case: you have changes in your tree when you realize you need amend | 19:00 |
| jam | as in, it takes the current content on disk | 19:00 |
| jam | and recommits it | 19:00 |
| jam | bialix: git commit --amend (I believe) will include those changes | 19:00 |
| jam | perhaps not if you haven't 'added' them? | 19:01 |
| bialix | hm | 19:01 |
| jam | not really sure | 19:01 |
| jam | but as I understood | 19:01 |
| jam | it was a way to resolve conflicts in the merge | 19:01 |
| jam | which means it has to include content changes as well as metadata changes | 19:01 |
| bialix | I was under impression it just create new commit object for old tree/blobs | 19:01 |
| bialix | it == git | 19:01 |
| emmajane | beuno-afk, ping when you've got a minute. | 19:01 |
| jam | bialix: The discussion I read about it was talking about what to do when an autocommit after-merge got something wrong | 19:02 |
| jam | and the recommendation was to use commit --amend | 19:02 |
| jam | hence... it has to change content somehow | 19:02 |
| garyvdm | bialix: bushy mysql branch: http://imagebin.ca/view/3GLAnke.html . I just expanded the twisties on the screen. It gets much wider that that... | 19:02 |
| bialix | I don't use git at all, only read the docs sometimes | 19:02 |
| jam | garyvdm: so... mysql also has the policy of letting anyone overwrite the mainline | 19:02 |
| jam | so "bzr merge trunk; bzr commit -m "merge trunk into my branch"; bzr push trunk" is acceptable to them | 19:03 |
| jam | which means their history is much harder to understand | 19:03 |
| garyvdm | jam: Yes. I chatted to vila about that at uds. They need a "land" command | 19:03 |
| jam | garyvdm: there are a lot of possibilities. They need to allow one first :) | 19:03 |
| jam | for example, setting 'append-revisions-only' would force the issue | 19:04 |
| jam | but they didn't want to impact the developers | 19:04 |
| garyvdm | I think I would find "land" command usefull too. | 19:04 |
| jam | garyvdm: what about 'bzr merge --swap-parents' ? | 19:04 |
| bialix | jam: one day after 2.0 I'll asking you a lot about file-specific commit messages. I want them in qbzr | 19:04 |
| * garyvdm goes to look | 19:04 | |
| jam | garyvdm: doesn't exist yet | 19:04 |
| jam | just ~ the same idea as land | 19:04 |
| garyvdm | :-) | 19:04 |
| garyvdm | Yes | 19:04 |
| garyvdm | land == merge --swap-parents | 19:05 |
| bialix | and we'll need commit --revision-properties-from-file FILE | 19:05 |
| bialix | merge-to | 19:05 |
| luks | I still think it's a bad idea | 19:06 |
| garyvdm | Hi luks, | 19:06 |
| luks | hey | 19:06 |
| garyvdm | Important for mysql people to use qbzr | 19:06 |
| bialix | lukc: which one? | 19:06 |
| luks | bialix: per-file commit messages as they are implemented in bzr-gtk | 19:06 |
| bialix | heh | 19:07 |
| bialix | they became stadard de-facto now | 19:07 |
| bialix | and only jam knows all secrets of them! | 19:07 |
| bialix | (joke) | 19:07 |
| luks | it just hides information if there is no official support in bzrlib | 19:08 |
| bialix | luks: this is the latest feature bzr-gtk has and we don't | 19:08 |
| garyvdm | bialix: we can start with showing per file commit messages in qlog, and qannotate (In the revision html view) | 19:08 |
| === pgega is now known as pgega|away | ||
| bialix | vila said me it's officially supported | 19:08 |
| bialix | or something like that | 19:08 |
| luks | bialix: yet bzr doesn't support them, loggerhead doesn't support them, etc. | 19:08 |
| garyvdm | I'm sure. I think mysql pays for bzr support. | 19:09 |
| bialix | garyvdm: yes, but we need commit support too | 19:09 |
| bialix | garyvdm: yes, although and not to us | 19:09 |
| garyvdm | :-) | 19:09 |
| bialix | so we can ignore these properties | 19:09 |
| bialix | it's just mater of competition with bzr-gtk | 19:10 |
| luks | I find it weird to update tools just to fit some weird workflow | 19:10 |
| luks | I can completely understand why it was done in bzr-gtk | 19:10 |
| garyvdm | Bialix: I think that mysql guys would love for qlog to show pfcm (per file commit messages) because bzr viz is unusable on the mysql branch. | 19:10 |
| bialix | because it's core gui tools | 19:10 |
| jam | garyvdm: As I Understand they have a custom "glog" which uses gtk widgets and does effectively qlog | 19:11 |
| bialix | bzr-gtk ^ | 19:11 |
| luks | heh | 19:11 |
| garyvdm | heh!~ | 19:11 |
| * bialix does not see difference | 19:11 | |
| garyvdm | just mainline, or expandable? | 19:12 |
| garyvdm | jam^ | 19:12 |
| jam | garyvdm: expandable | 19:13 |
| jam | bialix: 'bzr vis' doesn't have twisties | 19:13 |
| jam | so you get *all* revisions *all* the time | 19:13 |
| bialix | ah | 19:13 |
| bialix | so it quickly become unusable on big histories | 19:13 |
| jam | yep | 19:13 |
| garyvdm | I wonder why that is not in bzr-gtk. | 19:13 |
| jam | garyvdm: I really don't know | 19:13 |
| jam | other than some concerns about "not developing a VCS" to get in trouble with their existing bk license | 19:14 |
| garyvdm | any idea where I can find the code? | 19:14 |
| garyvdm | I c | 19:14 |
| jam | whether that has finally run out or not, I don't know | 19:14 |
| jam | guilheimb is the best mysql contact I know of | 19:14 |
| jam | he just sent an email to the list if you want to get his address | 19:14 |
| garyvdm | vila might know too | 19:14 |
| === bialix is now known as bialix-dinner | ||
| garyvdm | jam: I was thinking about storing gdfo, and I'm not sure why ghosts are a problem, because you can calculate the gdfo on commit, and then when you pull, you copy the gdfo from the branch you are pulling from? | 19:19 |
| jam | garyvdm: fetch can bring in a node which was a ghost locally without you realizing it | 19:20 |
| jam | garyvdm: http://paste.ubuntu.com/259422/ | 19:21 |
| jam | time goes down | 19:21 |
| jam | merging D into B will bring in the ghost | 19:21 |
| garyvdm | ok | 19:21 |
| jam | causing B to have a new gdfo | 19:21 |
| garyvdm | bla | 19:23 |
| garyvdm | jam: but the gdfo for b and d are know, and the gdfo for the new revision is the max(gdfo of parents) | 19:25 |
| garyvdm | max(gdfo of parents) +1 | 19:25 |
| jam | garyvdm: the gdfo for b *changes* when the ghost is filled in | 19:26 |
| jam | we need to detect that | 19:26 |
| jam | and propagate that change | 19:26 |
| jam | garyvdm: for example: http://paste.ubuntu.com/259426/ | 19:26 |
| jam | merging D into Z | 19:27 |
| * vila remembers when jam explained him the first time and send some love to garyvdm :-) | 19:27 | |
| jam | (so in those graphs, the first one has 'ghost' as a ghost, but the second has the actual revision.) | 19:27 |
| jam | if you merge D into Z | 19:27 |
| jam | it has to renumber, B, X, Y, Z | 19:27 |
| === vila is now known as vila-dinner | ||
| jam | In the first graph, we think the gdfo(B) == 2 (origin => A => B) | 19:28 |
| jam | however, after filling in the ghost it is 3 | 19:28 |
| jam | origin => A => C => ghost => B | 19:28 |
| jam | sorry. it is 4 | 19:28 |
| garyvdm | Are the ghost in that dag the same rev? | 19:29 |
| jam | garyvdm: right. In the first it is a real ghost, in the second it is a known revision | 19:29 |
| jam | (the whole point is that 'filling in ghosts' is a problem for caching gdfo) | 19:30 |
| jam | and unless you track a list of ghosts, it isn't cheap to determine what ghosts may have been filled in by fetch | 19:30 |
| jam | if any | 19:30 |
| garyvdm | Ok lest say the ghost is rev g | 19:30 |
| jam | sure | 19:30 |
| garyvdm | Who ever committed b would have had to have g in their repo | 19:31 |
| garyvdm | So the correct gdfo of g was know the b was commited | 19:31 |
| jam | garyvdm: yes. but bzr-svn has had a great knack for introducing a ghost in other people's repos | 19:32 |
| jam | and ... | 19:32 |
| jam | wouldn't store the gdfo property | 19:32 |
| garyvdm | So bzr-svn whould need to check for introducing a ghost on fetch, but normal bzr would not. | 19:33 |
| jam | garyvdm: it all depends on how ghosts can be created and when they can be filled | 19:35 |
| jam | converting from Arch is another way that ghosts were generated | 19:36 |
| jam | etc | 19:36 |
| garyvdm | jam: ok I see. | 19:36 |
| jam | And fetching bzr-svn => bzr branch can create a pure bzr branch that has a ghost | 19:36 |
| jam | and then fetching that bzr branch to another bzr branch can propagate that ghost | 19:36 |
| jam | and then fetching into that from the original bzr branch will fill in the ghost | 19:36 |
| jam | I can draw a diagram if you prefer | 19:37 |
| jam | basically, though, allowing a bzr revision to be stored in a non bzr location | 19:37 |
| garyvdm | DW. I understand. | 19:37 |
| jam | and then pulled out | 19:37 |
| jam | *could* introduce all kinds of craziness | 19:37 |
| garyvdm | Jam: and checking for ghosts on fetch would involve loading the whole graph. | 19:37 |
| jam | garyvdm: unless we start keeping a list somewhere of things that are ghosts. Yes | 19:39 |
| garyvdm | yes | 19:39 |
| jam | also, if you are loading the whole graph, you may as well number it from scratch | 19:39 |
| jam | since the numbering is ... low ms | 19:39 |
| jam | versus the loading | 19:39 |
| jam | I think gdfo on OOo is something like 700ms versus 10+s to load the whole graph | 19:40 |
| garyvdm | So is the plan to track the ghosts? | 19:40 |
| garyvdm | Hi amanica! | 19:40 |
| jam | garyvdm: well, if we want to cache gdfo, I think we have to track ghosts | 19:40 |
| jam | we don't do either yet | 19:40 |
| jam | vila-dinner is the one looking at that side of it | 19:41 |
| jam | :) | 19:41 |
| amanica | Hi garyvdm! :) | 19:41 |
| === bialix-dinner is now known as bialix | ||
| === EdwinGrubbs is now known as Edwin-lunch | ||
| garyvdm | jam: My ideas for KnownGraph, and question about find_ancestry are very brief, So I'll ask you here. | 19:50 |
| garyvdm | For KnownGraph, It would be nice if I could acquire via a public api the parents, and children for a revision. | 19:51 |
| garyvdm | Qlog uses that, I would be nice if there was just one copy. | 19:52 |
| jam | easy enough to add | 19:52 |
| jam | would you want it to be multi-way returning a dict? | 19:52 |
| jam | or just a single node? | 19:52 |
| garyvdm | Jam: just single node | 19:52 |
| jam | KG.get_parents(key) | 19:52 |
| jam | or KG.get_parent_map(keys) | 19:52 |
| jam | would you rather get the node directly, and have a way to walk node child and parents? | 19:53 |
| jam | or do you prefer to have KG as the pure api? | 19:53 |
| jam | (at the moment, the internals are slightly different between the KGN for python and pyrex) | 19:53 |
| garyvdm | KG.get_parents(key), KG.get_children(key) would be cool | 19:53 |
| garyvdm | I'll do a patch for that. | 19:54 |
| garyvdm | Ok 2nd question: This is how I'm using find_ancestry: http://paste.ubuntu.com/259445/ | 19:56 |
| garyvdm | Keys are in the format (revid,) | 19:56 |
| garyvdm | Is there a quick way to get just revid? | 19:56 |
| garyvdm | jam ^ | 19:57 |
| jam | key[-1] ? | 19:58 |
| jam | Also, I'm fairly sure that your else: clause will fail | 19:59 |
| jam | because CombinedGraphIndex doesn't implement _find_ancestors() only find_ancestry() | 19:59 |
| jam | oh, and revisions._index is not a CombinedGraphIndex | 19:59 |
| jam | but a _GCGraphIndex or a _KnitGraphIndex | 19:59 |
| * garyvdm tests. | 20:00 | |
| garyvdm | jam: I don't understand what ref_list_num is for. Is it ok for me to just pass 0, like you do in groupcompress.get_known_graph_ancestry? | 20:10 |
| jam | garyvdm: Indexes store a list of referenced revisions, which is repository specific | 20:11 |
| === CardinalXiminez_ is now known as CardinalFang | ||
| jam | it turns out that all current repos have the regular 'parents' as the first entry | 20:12 |
| jam | (KnitPack also stores the compression parent as the second entry, Groupcompress doesn't have a second entry) | 20:12 |
| jam | but it is why the index code doesn't claim to know the right value | 20:12 |
| jam | and gets it passed in from higher levels | 20:12 |
| garyvdm | I see, so I should just pass 0 then. | 20:13 |
| jam | garyvdm: you honestly shouldn't really be accessing that low of a level from qbzr | 20:13 |
| jam | as it could technically be different in a different repo | 20:13 |
| jam | for now, yes, you could just pass 0 | 20:15 |
| garyvdm | Ok - Then I need higher level way to get the whole ancestory from multiple repos. | 20:15 |
| lifeless | garyvdm: repository.get_graph() | 20:17 |
| garyvdm | lifeless: hi | 20:17 |
| jam | lifeless: well, he'd like to get it in a KnownGraph form. :) | 20:17 |
| lifeless | hi :) | 20:17 |
| garyvdm | Lifeless: I'm trying to take advantage of the better performance of find_ancestry | 20:18 |
| jam | garyvdm: you could do: g = repository.get_graph(other_repo); pm = dict((r, p) for r, p in g.iter_ancestry([tips]) if p is not None); kg = KnownGraph(pm) | 20:18 |
| jam | but that doesn't give you the benefit of faster ancestry search | 20:18 |
| jam | search/loading | 20:18 |
| lifeless | garyvdm: then you need to work on exposing it cleanly higher up | 20:19 |
| garyvdm | lifeless: Yes | 20:19 |
| lifeless | otherwise you'll just end up repeating all of te logic to handle stacking etc | 20:19 |
| garyvdm | jam: Any reason why not Graph.iter_ancestry could use find_ancestry? | 20:20 |
| chrispitzer | I want to branch a working copy off of my repo without keeping it connected to the repo. What's the command for this...? | 20:21 |
| jam | garyvdm: layering issues? | 20:21 |
| lifeless | chrispitzer: bzr branch | 20:21 |
| chrispitzer | yea, but then bzr push will go back to the parrent... won't it? | 20:21 |
| jam | it would certainly be the expected use case | 20:21 |
| chrispitzer | I don't want that | 20:21 |
| lifeless | then don't push ? | 20:21 |
| jam | but iter_ancestry is a bit silly to cast up into a generator when the lower level is creating dicts | 20:21 |
| garyvdm | jam: I c | 20:22 |
| lifeless | chrispitzer: if you create a separate branch, you can push anywhere you like | 20:22 |
| jam | garyvdm: also, I'm pretty sure get_known_graph_ancestry() doesn't handle stacking yet... | 20:22 |
| jam | as you have to explicitly support stacking everywhere, you never (anymore) get it for free | 20:23 |
| garyvdm | chrispitzer: You can remember a new push location with bzr push new_push --remember | 20:23 |
| jam | especially when you don't even get fallbacks over RemoteRepository anymore... | 20:23 |
| jam | garyvdm: and... nobody noticed that it was broken because again, stacking requires explicit testing, since it can't just be a permutation on existing formats... | 20:24 |
| garyvdm | jam: So in that case, I shall stick to using repo.get_graph().iter_ancestry( ) for now | 20:24 |
| * jam really dislikes the overall impact of stacking, as it breaks things over and over and over again | 20:24 | |
| jam | garyvdm: yeah probably | 20:25 |
| chrispitzer | thanks | 20:26 |
| bialix | jam: does stacking even worse os locks? | 20:29 |
| bialix | I don't believe | 20:29 |
| bialix | :-) | 20:29 |
| jam | bialix: stacking has caused more direct bugs in bzr than just about any other feature | 20:29 |
| bialix | direct bugs easier to fix? | 20:30 |
| jam | it requires a whole lot of code to know whether the thing it is looking at is stacked or not | 20:30 |
| jam | especially given that RemoteRepository is no longer abstracting away the fact of stacking | 20:30 |
| bialix | oh | 20:30 |
| jam | so the client now needs to know about stacking, and do operations 2x, etc. | 20:31 |
| jam | bialix: not to mention all the recent stuff about "filling in parent inventories", etc. | 20:31 |
| jam | which broke fetch, commit, merging a bundle, autopack, pack, upgrade, ... | 20:31 |
| bialix | I'm happy to not know about all this nightmares | 20:31 |
| bialix | but it scary | 20:32 |
| bialix | jam: btw, did you saw james_w's new bzr-builder plugin? | 20:33 |
| === Edwin-lunch is now known as EdwinGrubbs | ||
| garyvdm | jam: for KnownGraph.get_parents(key), should it check if the key is in the graph and return None if it is not, or just let a KeyError get raise? | 20:36 |
| jam | garyvdm: I would probably raise an exception | 20:36 |
| jam | I think the common uses | 20:37 |
| jam | mean that you should only be using keys that it has told you about | 20:37 |
| jam | so it is easier to write code that doesn't have to check if None | 20:37 |
| jam | the bigger question is what to return for ghosts? | 20:37 |
| garyvdm | ok | 20:37 |
| garyvdm | []? | 20:37 |
| jam | Since they have a node with parents of None | 20:37 |
| garyvdm | jam: [] would be the nicest for qbzr use. However, returning None may be usefull for other | 20:39 |
| garyvdm | users of the api | 20:39 |
| garyvdm | to know if a Node is a gost | 20:40 |
| jam | garyvdm: well, kg.merge_sort() now directly filters out ghosts nodes from the return value | 20:40 |
| jam | so you can pass in ghosts without having to filter | 20:40 |
| garyvdm | Ok, in that case, I'll just return None. | 20:41 |
| garyvdm | jam: Sorry to bother you so much. I've added a test that I expect to pass for the py version, and fail for the pyx version. But I don't get any failers. | 20:56 |
| garyvdm | How can I check that it is testing the pyx version. | 20:56 |
| jam | garyvdm: how are you creating the KnownGraph instance? | 20:56 |
| jam | self.create_known_graph() ? | 20:57 |
| jam | you can also just print kg | 20:57 |
| jam | and it should be obvious whether it is python or pyre | 20:57 |
| jam | pyrex | 20:57 |
| garyvdm | self.make_known_graph | 20:57 |
| garyvdm | ok | 20:57 |
| garyvdm | bla - I was running bzr selftest, not ./bzr selftest | 20:59 |
| jam | :) | 21:22 |
| lifeless | jam: shelf on windows nearly fixed. | 21:37 |
| lifeless | jam: is there a bug for it? | 21:37 |
| jam | lifeless: bug #305006 | 21:38 |
| ubottu | Launchpad bug 305006 in bzr "shelve fails on win32 with "Could not acquire lock"" [Medium,In progress] https://launchpad.net/bugs/305006 | 21:38 |
| jam | I believe | 21:38 |
| garyvdm | jam: Thanks alot for all the help. | 21:52 |
| garyvdm | Night all | 21:53 |
| lifeless | jam: hai five! | 22:05 |
| jam | ? got shelve to work? | 22:06 |
| jam | lifeless: grats | 22:06 |
| lifeless | yup | 22:06 |
| lifeless | 96 passing tests | 22:06 |
| lifeless | and a bit of test stipple cleaned up | 22:06 |
| lifeless | jam: branch is up, review request mailed. | 22:13 |
| lifeless | jam: only 5 thisFails calls in tree now. | 22:13 |
| lifeless | abentley: you might like to review it too, as I think you use shelf in pipelines implementation. | 22:15 |
| lifeless | abentley: are you around? I have a merge_inner question | 22:34 |
| abentley | lifeless: on the phone | 22:34 |
| lifeless | gimme a ping when you have a minute then. | 22:35 |
| lifeless | oubiwann: thanks | 22:46 |
| lifeless | oubiwann: shall look again | 22:46 |
| oubiwann | lifeless: sweet -- thanks! | 22:46 |
| lifeless | jam: thanks | 23:08 |
| bialix | does bzrlib has helper function to deteremine is given location (or pair tree/branch) is actually light checkout? | 23:20 |
| lifeless | <when he returns> bialix: I don't think so. tree.bzrdir.root_transport.base != tree.branch.bzrdir.root_transport_base though. | 23:27 |
| abentley | lifeless: ping | 23:40 |
| lifeless | abentley: hi. so there is a single test left that does locking operations that won't work on windows | 23:41 |
| lifeless | bzrlib.tests.per_workingtree.test_workingtree, test_merge_revert in that | 23:42 |
| lifeless | in that, the merge_inner call fails | 23:43 |
| lifeless | it fails because Merger replaces the base tree with a new revision tree | 23:44 |
| lifeless | but 'base' is a modified tree, so I'm not sure that its safe for Merger to do that. | 23:44 |
| lifeless | I'm hoping to get a better understanding from you of this part of the code base | 23:44 |
| abentley | lifeless: Where does this happen? | 23:44 |
| lifeless | in set_base_revision I think. I paged it out since I pinged you, and I'm running low on blood sugar now, I was about to eat when you pinged. | 23:45 |
| lifeless | Can you bear with me while I do that ? be about 10 minutes | 23:45 |
| abentley | lifeless: I'm looking.... | 23:46 |
| lifeless | if you want to see the error, remove the thisFailsS... line at the top of that test. | 23:47 |
| lifeless | back soon | 23:47 |
| abentley | lifeless: It looks like jam wanted to update Merger.base_rev_id, so he called set_base_revision, which has side effects that I can't imagine he wanted. | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!