| lifeless | igc: poolie: review plox https://code.edge.launchpad.net/~lifeless/bzr/bug-367632/+merge/8928 | 00:34 |
|---|---|---|
| litwol|mac | hello world | 00:42 |
| spiv | Gar, my wireless keeps bouncing. | 00:48 |
| litwol|mac | I've looked around but my lack of bzr knowledge is probably keeping me away from find the answer. i am looking for something similar to unfuddle that has bzr support. Does anyone know of such service ? | 00:49 |
| lifeless | whats unfuddle | 00:49 |
| litwol|mac | lifeless: http://www.google.com/search?client=opera&rls=en&q=unfuddle&sourceid=opera&ie=utf-8&oe=utf-8 | 00:49 |
| lifeless | launchpad.net | 00:50 |
| litwol|mac | That is one option, yes. | 00:50 |
| litwol|mac | Does any thing else come to mind ? | 00:50 |
| lifeless | savannah | 00:51 |
| lifeless | alioth | 00:52 |
| lifeless | sourceforge | 00:52 |
| === mordred_ is now known as mtaylor | ||
| * litwol|mac googles | 00:53 | |
| litwol|mac | lifeless: savannah.gnu.org ? | 00:53 |
| lifeless | yes, that has bzr support | 00:53 |
| lifeless | I'm curious why you seem to dislike launchpad.net | 00:53 |
| mwhudson | huh, unfuddle is a new one on me | 00:54 |
| litwol|mac | lifeless: silly reason really. i got spoiled by unfuddle's ease of use and pretty GUI | 00:54 |
| lifeless | well, launchpad.net has the prettiest gui of all the bzr hosting sites I know of, IMO | 00:55 |
| litwol|mac | i just finihed confirming account there :). though in the end i will have very little use of their GUI, its just nice when you're introduced to a project :). less things to go 'wtf' about. | 00:56 |
| litwol|mac | by the way i'm very new to bzr, haven't even got a single repo init'd | 00:57 |
| litwol|mac | Didn't want to bother until i found a way to host my repos remotely where proper backups exist :-p | 00:57 |
| litwol|mac | hopefuly... | 00:57 |
| poolie | hullo all | 00:59 |
| spiv | Hello. | 00:59 |
| litwol|mac | I heard bzr has very nice community with abundancy of documentation which is easy to understand.. unlike other solutions. | 00:59 |
| mwhudson | litwol|mac: yes, we keep backups :) | 01:00 |
| poolie | lifeless: i'll look | 01:01 |
| lifeless | thanks | 01:01 |
| litwol|mac | cool cool :) | 01:02 |
| poolie | what is the plat du jour at chez spiv? | 01:03 |
| litwol|mac | davidstrauss: "_ | 01:03 |
| litwol|mac | davidstrauss: :) | 01:04 |
| spiv | plat? My French vocab is pretty small... | 01:04 |
| davidstrauss | litwol|mac: hi | 01:04 |
| spiv | Oh, right. | 01:04 |
| mwhudson | spiv: for the not-very-frenched "plat du jour" is atomic :) | 01:06 |
| litwol|mac | davidstrauss: paul expressed his interest this morning to receive report if you haven't sent it yet . | 01:06 |
| spiv | mwhudson: right. In the regular context I'd have had no trouble :) | 01:11 |
| litwol|mac | davidstrauss: do you host your own repository for pressflow ? | 01:15 |
| davidstrauss | litwol|mac: yes | 01:16 |
| litwol|mac | davidstrauss: hmm. Would it be too much to ask for you to describe your process with backups and management to make sure it doesn't get destroyed in ______ [insert a horrible/unlucky scenario] | 01:17 |
| davidstrauss | litwol|mac: For my repo? | 01:17 |
| litwol|mac | yes | 01:17 |
| litwol|mac | davidstrauss: <<< /me 's learning process | 01:18 |
| davidstrauss | litwol|mac: It's stored on a Dell 2950 III with RAID-1 10K RPM SAS disks in a Rackspace datacenter. It's backed up nightly to a geo-redundant location. | 01:18 |
| davidstrauss | litwol|mac: But more importantly, every bzr checkout and branch I have of Pressflow has all the history, anyway. | 01:18 |
| litwol|mac | oho | 01:19 |
| litwol|mac | very nice. thx. | 01:19 |
| davidstrauss | litwol|mac: It is very hard to lose the history of a Bazaar project. Everyone has it. It replicates everywhere. | 01:20 |
| litwol|mac | hmm, you're right. I suppose i need to make an effort to avoid expectations based on my SVN/cvs experience | 01:21 |
| davidstrauss | litwol|mac: I should also note that the actual server is also in one of the most geologically and natural-disaster safe cities in North America: Dallas. | 01:21 |
| * litwol|mac nods | 01:22 | |
| davidstrauss | litwol|mac: Pressflow branches are probably one of the less important things on that box. | 01:22 |
| litwol|mac | hehe. i bet. | 01:22 |
| litwol|mac | i guess i need to find some docs on the subject of doing bzr backups. i know nothing bout it at this point. need to find out where all the hisotry is being kept. | 01:23 |
| litwol|mac | davidstrauss: thx for the info. I'll attempt to use something similar... although on a cheaper host :-p | 01:23 |
| lifeless | .bzr/repository | 01:23 |
| davidstrauss | litwol|mac: Making a bzr backup simply involves branching | 01:23 |
| fbond | This mean anything to anyone? | 01:23 |
| fbond | bzr: ERROR: Server sent an unexpected error: ('error', "open() got an unexpected keyword argument 'ignore_fallbacks'") | 01:23 |
| lifeless | fbond: outdated plugin on the server | 01:24 |
| litwol|mac | lifeless: oh!. thank you. | 01:24 |
| fbond | lifeless: Oh, probably loom. | 01:24 |
| lifeless | litwol|mac: but as davidstrauss says just doing bzr push <somewhere> will copy everything there | 01:24 |
| davidstrauss | litwol|mac: The first step to learning distributed tools is forgetting the annoying habits you've made using centralized ones. | 01:25 |
| litwol|mac | That i know. What i didnt know is which directory specifically i need to backup on that (or other) machine to really back it up. | 01:25 |
| * litwol|mac takes note. | 01:25 | |
| davidstrauss | litwol|mac: A push or branch does "really back it up" | 01:25 |
| * litwol|mac nods. | 01:25 | |
| davidstrauss | litwol|mac: The only thing you'd lose are ghost revisions, which are basically trash revisions, anyway. | 01:26 |
| * litwol|mac googles ghost revisions | 01:26 | |
| lifeless | litwol|mac: just backing up .bzr/repository doesn't backup branches or other metadata; but it does backup all the history | 01:26 |
| lifeless | litwol|mac: generally to backup just use your normal backup tools ;) | 01:26 |
| litwol|mac | lifeless: So what do i need to backup to perform an absolutely complete backup ? | 01:26 |
| lifeless | as long as you're not committing at the same time it will get a consistent snapshot | 01:26 |
| litwol|mac | lifeless: haha, i dont use anybackup tools yet. i'm trying to learn this stuff . | 01:26 |
| lifeless | well | 01:27 |
| lifeless | go get some ;) | 01:27 |
| fbond | lifeless: How can I push from a loom but only push the current thread as a normal branch? | 01:27 |
| lifeless | fbond: bzr init <target>; bzr push <target> | 01:27 |
| fbond | lifeless: Ah. | 01:28 |
| poolie | lifeless: done | 01:28 |
| lifeless | fbond: there is also bzr export-loom, which will export every thread | 01:28 |
| litwol|mac | Okey i think i've acquired enough info for now. i'll begin using it and i'm sure more specific questions will rise eventually. Cheers. | 01:28 |
| lifeless | poolie: thanks | 01:28 |
| litwol|mac | thank you davidstrauss and lifeless | 01:28 |
| poolie | lifeless: want to re-read my uifactory branch? | 01:28 |
| poolie | the incremental changes are fairly small | 01:28 |
| fbond | lifeless: Yeah, I was hoping to avoid all those branches. ;) | 01:28 |
| poolie | but i can't work out how to make lp give me the incremental diff | 01:28 |
| poolie | probably i need to guess which revision was proposed before based on the dates or something | 01:29 |
| poolie | i'll do that and attach it | 01:29 |
| lifeless | poolie: sure, url me up or get lp to drop me a mail | 01:29 |
| lifeless | poolie: I'm just implementing what we discussed yesterday | 01:29 |
| poolie | as far as the additional delta tests? | 01:30 |
| lifeless | tests and logic, yes ;) | 01:31 |
| poolie | lifeless: thinking about bryce's bug | 01:49 |
| poolie | i was contemplating a variation of check that would, very quickly: | 01:49 |
| lifeless | the big pack on windows one? | 01:49 |
| poolie | yeah, data loss apparently by the fs | 01:50 |
| poolie | there've been a couple like that | 01:50 |
| lifeless | we could read after write | 01:50 |
| poolie | anyhow: check the hash of the pack files; if any are broken move them aside and try to pull something back from obsolete_packs | 01:50 |
| lifeless | but thats rather slow except locally, and all it really shows is that its in cache | 01:50 |
| poolie | we could | 01:50 |
| poolie | right | 01:50 |
| poolie | i suspect it would only help roughly as much as sleep(n) would help | 01:50 |
| lifeless | and fsync() on networks is notoriously not-fsync | 01:51 |
| poolie | we should sync if we want to be paranoid... | 01:51 |
| lifeless | now interestingly | 01:51 |
| poolie | and, right | 01:51 |
| lifeless | hg has a thread right now | 01:51 |
| lifeless | about NULL's being written to windows fs's by file.append() | 01:51 |
| lifeless | which is the same API we use | 01:52 |
| lifeless | I think I'd put that functionality you suggest into either check or reconcile | 01:53 |
| lifeless | separately, I'm more interested in fixing the cause ;) | 01:54 |
| poolie | automatically pulling them back? | 01:54 |
| poolie | mm | 01:54 |
| poolie | well, i guess there's a few things | 01:54 |
| poolie | first, it'd be very quick compared to overall check to check the packs | 01:54 |
| lifeless | I don't mean magically | 01:54 |
| lifeless | it could be an option | 01:54 |
| poolie | second, you could try to pull obsolete packs out | 01:54 |
| poolie | but it's not guaranteed to fix it | 01:54 |
| lifeless | I just don't think a third data-integrity command is a good idea | 01:54 |
| poolie | yeah, when i said 'variation of check' i meant either a stage or an option | 01:56 |
| poolie | or both | 01:56 |
| poolie | not a new command | 01:56 |
| poolie | https://code.edge.launchpad.net/~mbp/bzr/387717-progress-bar-tty/+merge/9012 btw | 01:56 |
| lifeless | I'd like to see us make more of our core code more easily reusable. I just don't know how. Hooks are good. Layers are good. Separate packages would be interesting but perhaps a problem/difficult to manage | 01:57 |
| lifeless | poolie: why the change to SilentUIFactory's input? we use it in tests... | 02:00 |
| spiv | Yeah, there's some nice stuff in e.g. bzrlib.commands for instance that isn't particularly specific to a VCS at all. | 02:01 |
| lifeless | spiv: I've nearly got that completely detangled with my patches over the last couple of releases | 02:01 |
| spiv | Yeah, the code is pretty modular and independent. | 02:02 |
| poolie | lifeless: i think it's ill conceived, almost impossible to use correctly as it stands | 02:02 |
| poolie | do you really want to read user input with no prompts or output? | 02:02 |
| poolie | tests are better served by CannedInputUIFactory | 02:02 |
| spiv | But while it's part of bzrlib it's not really very convenient for others :/ | 02:02 |
| lifeless | poolie: well, we used apply_redirected to provide an appropriate stdin for SilentUIFactory | 02:03 |
| poolie | yeah | 02:03 |
| spiv | lifeless: I agree with your comments earlier/elsewhere about getting our unittest extensions into the wild and then, hopefully, into the stdlib. | 02:03 |
| lifeless | poolie: so I don't quite see the impossible aspect | 02:03 |
| poolie | well, i meant other than in testing | 02:03 |
| lifeless | btw, looks like I am doing SLUG's indepth talk this month | 02:03 |
| poolie | something like loggerhead doesn't want to be reading from stdin | 02:03 |
| lifeless | poolie: ah, now I see | 02:04 |
| lifeless | poolie: Ok, I'm +1 on making a clearer separation between silent and testing | 02:04 |
| poolie | and in tests | 02:04 |
| poolie | i think that applyRedirected means that you can't break in to pdb there | 02:04 |
| poolie | because it sees the redirected stdin etc | 02:04 |
| poolie | so that's an ugly big hammer compared to providing a CannedInputetc | 02:05 |
| lifeless | poolie: blackbox tests are the apply_redirected case | 02:05 |
| poolie | yeah | 02:05 |
| lifeless | poolie: they redirect stdout and stderr anyway | 02:05 |
| poolie | so there's a middle ground | 02:05 |
| poolie | real blackbox tests need redirection | 02:05 |
| lifeless | so pdb is totally borked regardless; redirecting stdin means that pdb at least doesn't hang | 02:05 |
| poolie | but ones that are just testing something ui related i think are happier with cannedinput | 02:05 |
| poolie | i think eventually it would be nice to do run_bzr with redirections that never actually uses sys.std* | 02:06 |
| poolie | so that pdb could still work | 02:06 |
| lifeless | I think that would reduce test coverage | 02:06 |
| poolie | in other words have the only access to those variables be constructing a uifactory bound to them at a level somewhere near run_bzr | 02:06 |
| lifeless | because the python standard library has a habit of writing to sys.std* | 02:06 |
| poolie | that may be true | 02:07 |
| lifeless | and we *do* catch deprecations and other nonsense from that level, in blackbox tests today | 02:07 |
| poolie | well | 02:07 |
| poolie | that is true that we may not be able to catch all code going there | 02:07 |
| poolie | s/going there/using sys.std* | 02:07 |
| poolie | it would probably be at least as reasonable to have those messages go to the test runner stderr | 02:07 |
| poolie | at the moment if the test doesn't check its stderr, they'll just be ignore | 02:08 |
| litwol|mac | oh! | 02:08 |
| poolie | ignored* | 02:08 |
| poolie | and i bet not all tests check it | 02:08 |
| litwol|mac | does bzr understand what 'lp:' is ? | 02:08 |
| lifeless | I try to have all my blackbox tests check stderr | 02:08 |
| lifeless | because of this | 02:08 |
| lifeless | litwol|mac: yes | 02:08 |
| litwol|mac | gosh i just spent 1/2 hour finding a way to branch LOL.. until it hit me that 'may be launchpad is tightly integrated with bzr such that bzr would know that lp means launchpad' | 02:08 |
| litwol|mac | gosh | 02:09 |
| litwol|mac | good stuff | 02:09 |
| poolie | anyhoo | 02:09 |
| poolie | we could also stash away real_std* somewhere and have a function that reestablishes them and calls pdb | 02:09 |
| spiv | litwol|mac: It's not so much tight integration as a simple plugin that's bundled with bzr, but yes :) | 02:09 |
| litwol|mac | Is there a way to port git history+branches (whole repo) over to bzr lp ? | 02:09 |
| litwol|mac | i'm sure there is, i rather should ask *how*? | 02:10 |
| lifeless | poolie: I like that we get real solid integration coverage with blackbox tests; I don't want to see us shrink that. I like the idea of getting pdb support in those tests if we don't shrink coverage | 02:10 |
| poolie | k, me too | 02:10 |
| poolie | anyhow, that's a later change | 02:10 |
| spiv | litwol|mac: there's a bzr fast-import plugin that can read the fast-import format dumps; there's also a bzr-git plugin that can read git repos directly (so you can use that to import their data into bzr format). | 02:10 |
| lifeless | poolie: finally, I don't think we *should need* pdb in blackbox tests, because they are meant to be smoke-level, not comprehensive, and if we can't tell whats going on enough to write a lower level test, we'll have trouble handling user bug reports too | 02:10 |
| poolie | :/ | 02:11 |
| lifeless | poolie: that thats a motivation-for-me thing, not a reason to avoid putting pdb support in | 02:11 |
| spiv | litwol|mac: Launchpad has an import-from-git service builtin, btw | 02:11 |
| litwol|mac | oh | 02:11 |
| * litwol|mac goes to find it | 02:11 | |
| spiv | (built on bzr-git) | 02:11 |
| lifeless | poolie: does that make sense? I'll happily support having pdb in blackbox tests for folk that want it, so long as we don't shrink coverage to get it. | 02:11 |
| RAOF | spiv: But launchpad's service will only import a single branch, right? | 02:12 |
| litwol|mac | oh crap | 02:12 |
| spiv | RAOF: just trunk, yes. | 02:12 |
| litwol|mac | i broke LP :-\ | 02:12 |
| litwol|mac | (Error ID: OOPS-1299A140) | 02:12 |
| ubottu | https://lp-oops.canonical.com/oops.py/?oopsid=1299A140 | 02:12 |
| RAOF | litwol|mac: There's the git-import command (from bzr-git), which will create one branch per git branch. You could then push all those to launchpad separately. | 02:13 |
| litwol|mac | i wont be able to figure it out (yet) without a walkthrough tutorial... i just started >. | 02:13 |
| poolie | so | 02:13 |
| poolie | we want those tests to be realistic | 02:13 |
| poolie | for what happens when you actually run bzr | 02:14 |
| poolie | i'd draw an analogy to the fact that we don't start a new python subprocess for every blackbox invocation | 02:14 |
| poolie | doing so would in a sense give better coverage | 02:14 |
| lifeless | indeed | 02:14 |
| poolie | but not in a very useful way | 02:14 |
| poolie | and at a high price | 02:14 |
| RAOF | litwol|mac: Well, git-import would be easy; you could just "bzr git-import $REPOSITORY" to grab all the branches. But you probably want to do that inside a bzr repository, for speed and space. | 02:15 |
| poolie | in this particular thing | 02:15 |
| poolie | well | 02:15 |
| poolie | actually, i'm planning to keep chipping away at this | 02:15 |
| poolie | it sounds like we're not greatly at odds | 02:15 |
| poolie | so let's talk about the next step when i get there? | 02:16 |
| lifeless | the docstring for zrlib/ui/__init__.py may want to list CannedUIFactory | 02:16 |
| poolie | k | 02:16 |
| poolie | probabyl | 02:16 |
| lifeless | poolie: its a long patch, so is it ok with you if I just make notes here? | 02:16 |
| lifeless | and yes, lets talk more later | 02:16 |
| lifeless | the long comment in that file talks about what we /had/ | 02:17 |
| lifeless | I think it would be better to be totally in the now | 02:17 |
| lifeless | and if you want to avoid folk reintroducing subclassing, say so directly | 02:17 |
| lifeless | it might even be best as the class docstring for TextUIFactory, so that pydoc shows it | 02:18 |
| lifeless | or split between the base class and TextUIFactory | 02:18 |
| lifeless | lastly, some tests for CannedUIFactory, if you haven't got any (I can't tell from the patch), would be great | 02:19 |
| RenatoSilva | verterok: hi | 02:19 |
| lifeless | poolie: ^ review done | 02:22 |
| poolie | lifeless: just what you said there? | 02:23 |
| poolie | or also on the web? | 02:23 |
| lifeless | just here | 02:23 |
| poolie | oh ok | 02:24 |
| poolie | i just saw your comment | 02:24 |
| poolie | <lifeless> poolie: ah, now I see | 02:24 |
| poolie | <lifeless> poolie: Ok, I'm +1 on making a clearer separation between silent and testing | 02:24 |
| poolie | good :) | 02:24 |
| lifeless | :P | 02:25 |
| poolie | so, basically just improving the documentation? | 02:25 |
| lifeless | yah | 02:25 |
| poolie | and the tests for CannedUIFactory | 02:26 |
| poolie | ok | 02:26 |
| lifeless | oh one more thing | 02:26 |
| lifeless | a test for assertRaises | 02:26 |
| poolie | actually this is a kind of interesting question | 02:26 |
| lifeless | as you've changed it too | 02:26 |
| poolie | we'd kind of like parameterized per_uifactory tests | 02:26 |
| poolie | to assert all the methods are covered for every implementation | 02:26 |
| poolie | but the way they're tested will vary | 02:27 |
| poolie | hm | 02:27 |
| RenatoSilva | how is this page generated, manually? http://doc.bazaar-vcs.org/bzr.1.17/en/release-notes/NEWS.html#bzr-0-0-0-69-2005-03-22 | 02:29 |
| lifeless | RenatoSilva: cron + make doc | 02:29 |
| lifeless | poolie: so, the contract is the methods that can be called on it | 02:29 |
| lifeless | poolie: the outcomes are specific to scenario | 02:29 |
| poolie | right | 02:30 |
| lifeless | include outcomes in the parameterisation | 02:30 |
| lifeless | perhaps as curried things | 02:31 |
| RenatoSilva | lifeless: a scheduled cron job running make's doc target? | 02:31 |
| lifeless | RenatoSilva: yes | 02:31 |
| poolie | RenatoSilva: is it broken or something? or you're just curious? | 02:31 |
| RenatoSilva | lifeless: I'm not familiar with make, but what is the source of such information? Is it some text file updated manually? | 02:32 |
| RenatoSilva | poolie: curious | 02:32 |
| spiv | Reminds me a bit of the smart protocol tests: v1,v2,v3 all support a common set of features (requests with and without bodies, etc.), but the outcomes are different so it was hard to think of a way to reuse the tests. | 02:33 |
| lifeless | RenatoSilva: make is a build system, it reads rules from 'Makefile', which we have in the top of the bzr source tree | 02:33 |
| poolie | spiv, so what did you do? | 02:33 |
| spiv | Currently there's no real reuse :( | 02:33 |
| lifeless | spiv: re; being in bzrlib; it does get bzrlib 'out there' :P | 02:33 |
| spiv | I did experiment with a test that all the v1 test *names* were also present on the v2 and v3 test cases. | 02:34 |
| spiv | It actually found some small gaps, but the test itself was too ugly to merge. | 02:34 |
| RenatoSilva | lifeless: the Makefile calls a self-made tool for generating such doc, isn't it | 02:34 |
| spiv | poolie: so, basically, if you find a good answer, I'm interested :) | 02:34 |
| poolie | mm | 02:35 |
| spiv | Because I'm not particularly happy with test_smart_transport atm. | 02:35 |
| poolie | at that point you might be better just measuring coverage | 02:35 |
| spiv | Well, I think coverage would be a complementary thing to measure, not a replacement. | 02:35 |
| lifeless | RenatoSilva: at this point, I suggest you look at the Makefile :) | 02:36 |
| RenatoSilva | lifeless: ok | 02:36 |
| lifeless | RenatoSilva: you've hit my cache threshold | 02:36 |
| spiv | It did like the explicit statement that "every feature/behaviour we check for v1 should also be checked for v2/v3" | 02:36 |
| RenatoSilva | heheh | 02:37 |
| spiv | It would help in making sure the test method names (on the already large test case classes) wouldn't diverge too much, that the testing strategy was in sync across all three implementations. | 02:38 |
| spiv | But the combination of the oddness of having a meta-test, and that actually there are parts where v1/v2/v3 intentionally diverge in behaviour, made it awkward. | 02:39 |
| spiv | I still like the idea, though :) | 02:39 |
| RenatoSilva | any date for a 1.17 windows installer? | 02:41 |
| spiv | mwhudson: litwol|mac's earlier OOPS looks like a code import form bug: https://lp-oops.canonical.com/oops.py/?oopsid=1299A140 | 02:54 |
| mwhudson | spiv: | 02:54 |
| mwhudson | https://bugs.edge.launchpad.net/launchpad-code/+bug/397220 | 02:54 |
| ubottu | Ubuntu bug 397220 in launchpad-code "Better validation for project field in new code import form" [High,In progress] | 02:55 |
| mwhudson | actually fix committed now | 02:55 |
| spiv | mwhudson: hooray! | 02:55 |
| mwhudson | spiv: and one revision away from edge, in fact | 02:55 |
| spiv | mwhudson: heh. | 02:56 |
| * igc food | 03:13 | |
| JoaoJoao | hello | 03:19 |
| === edcrypt_ is now known as edcrypt | ||
| |malibu| | Does anyone know how to tell where your plugins directory is? | 04:33 |
| lifeless | bzr plugins -v, I think | 04:33 |
| lifeless | will show where each plugin has been loaded from | 04:33 |
| |malibu| | I have one in python2.5 path, one in python2.6 path, one in /usr/share/pyshared/bzrlib | 04:33 |
| |malibu| | ok will try | 04:33 |
| lifeless | if you mean where your per user directory is, bzr --version shows the config directory, and you can add a plugins directory there | 04:34 |
| |malibu| | ok thanks.. that's probably more appropriate | 04:34 |
| poolie | igc, nice work with the sphinx stuff | 04:47 |
| poolie | i thought we'd use that only for the doc generation though | 04:47 |
| poolie | it looks like you've put the overall site structure into it | 04:47 |
| igc | thanks poolie. Whatever you think - a mockup is a mockup | 05:00 |
| poolie | yeah, the choice of tool for the mockup doesn't matter a lot | 05:00 |
| igc | poolie: as long as it drives the right conversation wrt content, then it's valuable | 05:01 |
| poolie | but apparently i had missed your point yesterday | 05:01 |
| poolie | i hadn't seriously considered using sphinx for the whole site | 05:01 |
| poolie | maybe we should.... | 05:01 |
| Arrrgh | hi guys. I'm developing a VS plugin for Bazaar and have some problems understanding it's behavior. Anyone can help me? | 05:12 |
| lifeless | sure | 05:12 |
| lifeless | you might want to ask a question :) | 05:12 |
| RenatoSilva | Visual Studio? | 05:14 |
| Arrrgh | well.. when I rename some folder with files and after run "bzr status" for any files inside, it shows empty status :-/ Is this a bug? | 05:14 |
| Arrrgh | yes, Visual Studio | 05:14 |
| lifeless | Arrrgh: its not a bug, those files haven't changed | 05:14 |
| lifeless | if you just run 'bzr st' it will show the folder as renamed | 05:14 |
| lifeless | I'm completing a change at the moment that will make bzr st report the folder as renamed when you run 'bzr st' inside it | 05:15 |
| lifeless | or for files inside it | 05:15 |
| RenatoSilva | isn't renaming tracked by bzr? I thought so... | 05:15 |
| lifeless | RenatoSilva: it is, the files haven't been renamed. | 05:15 |
| Arrrgh | nice. when it'll be ready? | 05:16 |
| lifeless | Arrrgh: tomorrow I suspect | 05:19 |
| lifeless | Arrrgh: its a side effect of a change being made to ensure that partial deltas are always safe to apply to the source tree | 05:19 |
| Arrrgh | anyway, it'll make this part of my work much easier =) | 05:20 |
| * RenatoSilva gtg, thanks evybody | 05:28 | |
| spiv | Updated inventory-delta patch up for review. | 05:34 |
| * spiv -> lunch | 05:34 | |
| lifeless | spiv: oh | 05:34 |
| lifeless | spiv: if it doesn't get parameterised tests from test_inv, please add that in :P | 05:34 |
| lifeless | spiv: it should I think, if it uses Repository.add_inventory_by_delta | 05:35 |
| spiv | It does use that, yes. | 06:00 |
| spiv | Thanks. | 06:00 |
| lifeless | spiv: cool, as long as it doesn't add surface area that could be wrong I think its fine not to specifically interface test it | 06:05 |
| lifeless | spiv: if it does add surface area (and perhaps it does, by having a new kind), then I'd be inclined to get it tested | 06:05 |
| verterok | lifeless, thumper: ^ atm only bzr project group ;) | 06:07 |
| verterok | hi bazaaristas! | 06:08 |
| verterok | I'm pleased to introduce hal_, among other things the review list bot | 06:09 |
| verterok | hal_ accepts commands like:@command_name and some commands via privmsg, e.g: @reviewlist or /msg hal_ reviewlist | 06:10 |
| hal_ | https://launchpad.net/~spiv/bzr/inventory-delta/+merge/9125 | No reviews | 06:10 |
| hal_ | https://launchpad.net/~mbp/bzr/387717-progress-bar-tty/+merge/9012 | No reviews | 06:10 |
| hal_ | https://launchpad.net/~bzr/bzr/smooth-upgrades/+merge/8921 | No reviews | 06:10 |
| hal_ | https://launchpad.net/~ndurner/bzr/bzr-ftp/+merge/8906 | Needs Fixing: 1 | 06:10 |
| hal_ | https://launchpad.net/~jameinel/bzr/1.18-stack-and-annotate-393366/+merge/8840 | No reviews | 06:10 |
| hal_ | https://launchpad.net/~abentley/bzr/devnotes/+merge/8766 | No reviews | 06:10 |
| hal_ | https://launchpad.net/~amanica/bzr/log_returns_too_much/+merge/8538 | Approve: 1 | 06:10 |
| hal_ | https://launchpad.net/~mbp/bzr/391411-reconfigure-stacked/+merge/8527 | Needs Fixing: 1 | 06:10 |
| hal_ | https://launchpad.net/~garyvdm/bzr/register_lazy_decorated/+merge/8430 | No reviews | 06:10 |
| hal_ | https://launchpad.net/~amanica/bzr/mv_after/+merge/8179 | Approve: 1 | 06:10 |
| hal_ | https://launchpad.net/~bzr/bzr/faster-commit-file/+merge/7885 | Needs Fixing: 1 | 06:10 |
| hal_ | https://launchpad.net/~ian-clatworthy/bzr/faster-dirstate-saving/+merge/7537 | No reviews | 06:10 |
| hal_ | https://launchpad.net/~ian-clatworthy/bzr/faster-log-file/+merge/7535 | No reviews | 06:10 |
| hal_ | https://launchpad.net/~lifeless/bzr/check-1/+merge/7489 | Approve: 1 | 06:10 |
| hal_ | https://launchpad.net/~mhammond/bzr/update-r/+merge/6980 | Needs Information: 1 | 06:10 |
| hal_ | https://launchpad.net/~wjl/bzr/bug-317644/+merge/6978 | Resubmit: 1 | 06:10 |
| hal_ | https://launchpad.net/~lovesyao/bzr/windows-utf8/+merge/1806 | Abstain: 1, Needs Fixing: 1 | 06:10 |
| verterok | a new name for the bot is welcome :) | 06:12 |
| lifeless | verterok: cool, thanks | 06:13 |
| verterok | lifeless: np :) | 06:14 |
| fullermd | Yeah, considering HAL's behavior, I don't think we'd want him taking charge of reviews :p | 06:14 |
| lifeless | the user name review isn't taken | 06:14 |
| lifeless | or, at least, not obviously | 06:14 |
| verterok | fullermd: heh | 06:14 |
| poolie | verterok: nice one | 06:20 |
| poolie | verterok: maybe it could use irc color codes for the status? | 06:20 |
| verterok | poolie: :) | 06:20 |
| bob2 | ansi blink sequence for critical unreviewed bugs | 06:20 |
| verterok | poolie: sure!, but I know nothing about irc colors. if someone paste the strings, I'll use that :) | 06:21 |
| poolie | lifeless: when you said i changed assertRaises i assume you mean assertIsInstance | 06:21 |
| poolie | i'll check its tests | 06:22 |
| poolie | verterok: hello? | 06:23 |
| poolie | woo | 06:23 |
| poolie | bold | 06:23 |
| poolie | http://www.ircbeginner.com/ircinfo/colors.html | 06:23 |
| poolie | so it's just the ascii for ctrl-k, b, u, r, etc | 06:23 |
| verterok | poolie: hi | 06:24 |
| verterok | ack | 06:24 |
| verterok | :) | 06:24 |
| poolie | chaos reigns | 06:24 |
| lifeless | poolie: yes | 06:24 |
| * fullermd wonders if lifeless is confirming asserts or chaos... | 06:25 | |
| mwhudson | luckily my client doesn't support colour | 06:25 |
| lifeless | poolie: meep no colours! | 06:25 |
| mwhudson | (or said support is turned off) | 06:25 |
| mwhudson | poolie: hi CTCP! | 06:26 |
| poolie | you must have it off or something | 06:26 |
| lifeless | it could well be filtered in the channel | 06:27 |
| lifeless | I get lovely plain text | 06:27 |
| bob2 | channel is +c | 06:28 |
| bob2 | "This cmode activates the colour filter for the channel. " | 06:28 |
| poolie | ah, i see them going out, of course | 06:29 |
| poolie | i guess it's require dealing with either abuse or freenode egotrips | 06:29 |
| poolie | :/ | 06:29 |
| ndurner | Hi poolie! | 06:33 |
| ndurner | I have made the changes you suggested to my tree and replied to the merge proposal. | 06:33 |
| poolie | yes i saw | 06:35 |
| poolie | i'll try to re-read it but it sounds like it's all good now | 06:35 |
| ndurner | okay :-) | 06:36 |
| poolie | ndurner: oh i thought of one other thing - can you print the error to the user, rather than just to the log, if it makes sense | 06:38 |
| poolie | lifeless: oh i think it might make that list more readable | 06:38 |
| ndurner | sure | 06:40 |
| lifeless | poolie: No comment ;). It might be nice to sort it though | 06:41 |
| poolie | or maybe align the votes to the front | 06:42 |
| poolie | that might be easier than coloring | 06:42 |
| lifeless | poolie: colour doesn't mean much to me, until its painful, which is why I rarely reach for it as a tool | 06:42 |
| spiv | It's a shame that there's no short identifier like a single number that list can use. | 06:43 |
| poolie | heh | 06:44 |
| poolie | we just had that conversation with jml :) | 06:44 |
| spiv | The #twisted equivalent just lists trac ticket numbers, like "#aaa (spiv), #bbb, #ccc (fred), ...", all on one line. | 06:44 |
| spiv | Ah, ok. | 06:44 |
| poolie | he didn't want to emphasize the mp numbers | 06:44 |
| jml | hahaha | 06:44 |
| poolie | and he has a point, | 06:45 |
| poolie | but the desire for a short id remains | 06:45 |
| lifeless | was it voice? | 06:45 |
| spiv | Yeah, meaningless numbers do suck. | 06:45 |
| poolie | maybe they should be abbreviated by the bug number | 06:45 |
| jml | spiv, there's a bug that you can wage in on | 06:45 |
| spiv | But short ids are still nice :) | 06:45 |
| poolie | having (slightly) overlapping integer sequences is unoptimal | 06:45 |
| lifeless | you could hash them all | 06:45 |
| jml | lifeless, only a little, everything interesting is on the bug reports. | 06:45 |
| spiv | With the current LP model, the lp:~spiv/bzr/foo branch name is actually a possible key. | 06:46 |
| jml | spiv, it's an almost-key | 06:46 |
| bob2 | etoolong | 06:46 |
| lifeless | spiv: its not unique though | 06:46 |
| spiv | Yeah, but there can only be one active proposal per branch AIUI? | 06:46 |
| jml | spiv, this is one of the rare times where I disagree with mpt on what the ideal UI should be. | 06:46 |
| spiv | And this list is all about active proposals, after all. | 06:47 |
| lifeless | spiv: not AIUI | 06:47 |
| spiv | jml: :) | 06:47 |
| poolie | i think the user model for the meaning of an mp is unclear | 06:47 |
| jml | spiv, but if I'm disagreeing with you, poolie & mpt then maybe I'm wrong | 06:47 |
| poolie | like if you update and come back, do you create a new one? | 06:47 |
| poolie | current practice says yes but it's not actually needed | 06:47 |
| lifeless | spiv: what does mpt want? | 06:47 |
| poolie | of course getting the experience with it is useful | 06:47 |
| lifeless | sorry | 06:48 |
| lifeless | jml: what does mpt want? | 06:48 |
| * jml pulls up the bug report | 06:48 | |
| poolie | ndurner: if you just change that i'll approve it | 06:49 |
| poolie | a test would be nice... | 06:49 |
| poolie | if you ask vila he might write one | 06:49 |
| jml | lifeless, mpt wants the canonical, final URL of a merge proposal to be something like https://code.launchpad.net/merge/5520 | 06:49 |
| jml | https://bugs.edge.launchpad.net/launchpad-code/+bug/400215 | 06:49 |
| ubottu | Ubuntu bug 400215 in launchpad-code "Merge proposal URLs are ugly and needlessly long" [Undecided,Incomplete] | 06:49 |
| lifeless | jml: I'd like to have that as an alias | 06:50 |
| lifeless | jml: further, I'd like to be able to merge from it | 06:50 |
| lifeless | I don't care if the current merge proposal urls stay or go | 06:50 |
| poolie | jml, i'd kind of rather have bugs.launchpad.net/400215/+proposal | 06:50 |
| poolie | for the common case that there's one per bug | 06:50 |
| poolie | this is just a random thought not a proposal | 06:50 |
| lifeless | poolie: I suggest that that would be good as an alias, rather than a primary | 06:50 |
| jml | lifeless, yes. poolie filed a bug about that first one, which is linked from that page. | 06:51 |
| jml | lifeless, followed up with a bug about making the merge id prominent in the page & <title> | 06:51 |
| jml | lifeless, and I think there's probably already a bug about being able to merge from the merge proposal url. | 06:51 |
| jml | hmm. | 06:51 |
| jml | I'd like to go into how I would redesign the merge proposal system | 06:52 |
| lifeless | if you use a branch reference at the mp url | 06:52 |
| poolie | i think you have a good point about a risk of premature grasping in saying "ooh a number let's use it" | 06:52 |
| jml | but I won't, because I want to fix this easy & vitally important bug. | 06:52 |
| lifeless | bzr will make merge Just Work | 06:52 |
| poolie | yeah way to go :) | 06:52 |
| poolie | lifeless: that works now, or it used to | 06:52 |
| lifeless | poolie: it doesn't dtrt | 06:52 |
| poolie | bzr walks up til it finds the branch page and that points to the right place | 06:52 |
| lifeless | poolie: because it does a partial merge | 06:52 |
| jml | lifeless, yeah, I seem to recall that implementation approach mentioned on the bug report too. | 06:52 |
| poolie | oh, of a file that doesn't exist? | 06:52 |
| lifeless | poolie: its /close/ but not correct | 06:52 |
| poolie | yeah that would suck | 06:53 |
| ndurner | poolie: it's in r4543. | 06:54 |
| ndurner | (just committed) | 06:55 |
| poolie | biab, going out for air before it rains. | 07:04 |
| poolie | i hope | 07:04 |
| thumper | Can someone please take a look at https://launchpad.net/~abentley/bzr/devnotes/+merge/8766 | No reviews ? | 07:09 |
| thumper | I got Aaron to make sure he wasn't blocking this | 07:10 |
| thumper | now it is blocked on you guys | 07:10 |
| * ndurner hurries to work | 07:16 | |
| GaryvdM | Morning | 07:16 |
| igc | hi garyvdm | 07:19 |
| igc | thumper: I'm planning to review it this week | 07:19 |
| igc | bbiab | 07:19 |
| lifeless | EOD | 07:25 |
| lifeless | iter_changes is making good progress | 07:25 |
| nil1 | back (ndurner) | 07:51 |
| lifeless | jml: ping, subunit, review & design | 08:20 |
| jml | lifeless, I'm pretty busy this evening, I'm sorry. | 08:21 |
| lifeless | jml: thats ok | 08:22 |
| lifeless | jml: when you can though :) | 08:26 |
| jml | lifeless, will let you know. | 08:27 |
| jml | lifeless, I've got a talk I need to prepare for tomorrow. | 08:27 |
| lifeless | whats tomorrow? | 08:27 |
| lifeless | oh fpsyd? | 08:27 |
| lifeless | good luck with it | 08:28 |
| jml | fp-syd | 08:28 |
| jml | lifeless, they were short of speakers, and I said I had a lightning talk already prepared that I could probably pad out | 08:28 |
| jml | thanks. | 08:28 |
| jml | I'm hoping by the end of it, I'll understand monads better :) | 08:29 |
| lifeless | jml: I'd come along and heckle^Wlisten attentively, but sadly I have a standing booking thursdays | 08:31 |
| jml | lifeless, oh well. | 08:32 |
| === j^_ is now known as j^ | ||
| * igc dinner - night all | 09:19 | |
| jelmer | luks: hi | 10:19 |
| luks | hey | 10:20 |
| jelmer | luks: Did you still have that svn merge directive code around somewhere? | 10:20 |
| jelmer | I was looking into writing something similar for bzr-git and I guess it would be a good starting point | 10:20 |
| luks | jelmer: https://code.launchpad.net/~luks/bzr-svn/send | 10:21 |
| jelmer | luks: awesome, thanks! | 10:21 |
| luks | jelmer: but right now it does only what's necessary to fool review board | 10:21 |
| luks | I'd like to implement full svn-like diff later | 10:22 |
| jelmer | luks: ok | 10:28 |
| lifeless | jelmer: hai | 10:30 |
| jelmer | lifeless: g'day | 10:31 |
| lifeless | jelmer: can I beg a subunit review off you? | 10:32 |
| jelmer | lifeless: which bit in particular? | 10:33 |
| jelmer | oh, the time stuff? | 10:33 |
| lifeless | yes | 10:33 |
| lifeless | thats the first half of it | 10:34 |
| lifeless | second half is about to get committed and pushed | 10:34 |
| lifeless | you could review that too if you're feeling up to it ;) | 10:36 |
| jelmer | lifeless: we seem to be including two copies of iso8601.py ? | 10:38 |
| lifeless | jelmer: ?! let me look | 10:38 |
| jelmer | lifeless: oh no | 10:39 |
| jelmer | lifeless: false alarm | 10:39 |
| jelmer | lifeless: Sorry :-( | 10:39 |
| lifeless | jelmer: I wanted to keep the upstream stuff around | 10:39 |
| lifeless | I'm pushing the generation of timestamps stuff now | 10:39 |
| lifeless | done | 10:39 |
| lifeless | this should allow some pretty easy analysis of test performance | 10:40 |
| lifeless | I'll resubmit the branch as you're here :) | 10:41 |
| lifeless | https://code.edge.launchpad.net/~lifeless/subunit/time-support/+merge/9136 is the new review | 10:42 |
| jelmer | lifeless: thanks | 10:43 |
| jelmer | Kinnison: are you still around here somewhere? | 11:58 |
| flutherben | Question: I'm using a pretty large, and pretty old bzr repository (maybe 3 years). I've just upgraded to 1.17, but it's still really slow. Should I do a "bzr upgrade" on my repo? Will it be stable? | 12:06 |
| LarstiQ | flutherben: what does `bzr info` on that repo say? | 12:07 |
| flutherben | Shared repository with trees (format: rich-root-pack) | 12:08 |
| Kinnison | jelmer: aye, hacklab 1 | 12:08 |
| Kinnison | jelmer: I'm currently trying to document some IEEE 802.15.4 stuff, so feel free to interrupt | 12:08 |
| LarstiQ | flutherben: you might gain from an uprgade then. What are you experiencing slowness with? | 12:09 |
| flutherben | checkins, updates, merges | 12:10 |
| flutherben | it seems even slower after the update | 12:10 |
| flutherben | I had to download something with Hg a day ago, and it was 10-100x the speed. Made me think something is wrong with my repo | 12:11 |
| flutherben | You think I'll see gains in speed? Is there any risk of instability? | 12:13 |
| LarstiQ | flutherben: instability in what sense? | 12:13 |
| flutherben | Well, I just mean all the same bzr functionality is well supported, and I shouldn't be worried about corruption or anything. As in, ready for a production environment | 12:14 |
| LarstiQ | flutherben: of course | 12:14 |
| flutherben | excellent | 12:14 |
| LarstiQ | flutherben: 2a still might hit some codepaths that aren't as optimized as possible, but it works | 12:15 |
| jelmer | Kinnison: heading over.. | 12:15 |
| LarstiQ | flutherben: if you don't want to go with 2a just yet, you can use the 1.14 format | 12:15 |
| flutherben | What's the difference? | 12:15 |
| DaffyDuck_ | I have a shared repository which has the permissions rwxrws---. In there I created a directory dev (with the same persmissions) and ran "bzr init" inside it. The subdirectories and files appear to have the correct permissions. But when I branch it "bzr branch dev stable", the stable directory gets rwxr-xr-x. (run as root). Do I need to fiddle around with umask to get the proper permissions on new branches in the repository? | 12:16 |
| LarstiQ | DaffyDuck_: I'd recommend posix acls | 12:18 |
| LarstiQ | flutherben: 1.14 has been around longer, 2a is much much better | 12:18 |
| flutherben | 2a sounds better then :) | 12:18 |
| flutherben | 2a is --rich-root-development? | 12:19 |
| LarstiQ | flutherben: Launchpad is in 2a, and bzr development will switch soon | 12:19 |
| LarstiQ | flutherben: no, --2a | 12:19 |
| flutherben | ah | 12:19 |
| LarstiQ | flutherben: so the consequence here is that if you use older clients, pre 1.16 iirc, they won't be able to read 2a | 12:19 |
| flutherben | yeah, I'm basically just using 1.16/1.17 from console | 12:20 |
| LarstiQ | flutherben: sounds fine then | 12:20 |
| DaffyDuck_ | LarstiQ: Assuming I don't have access to posix acls... | 12:20 |
| flutherben | ok, anything I need to know about backing up and upgrading? | 12:20 |
| flutherben | I can just make a copy of my whole repository before I upgrade? | 12:20 |
| LarstiQ | flutherben: just running `bzr upgrade` should be enough, it will make a backup of .bzr | 12:21 |
| flutherben | sweet | 12:21 |
| LarstiQ | flutherben: but security comes in layers, so make an extra backup if that makes you feel safer | 12:21 |
| flutherben | yeah, I probably will | 12:21 |
| flutherben | thanks a lot LarstiQ | 12:21 |
| LarstiQ | flutherben: np. I'd like to hear what that does for your speed experience. | 12:22 |
| flutherben | Yeah, I'll check back in and let you know | 12:22 |
| LarstiQ | flutherben: do you only work local, or also interact with remote branches? | 12:22 |
| LarstiQ | flutherben: because bzr+ssh is again faster than sftp/http | 12:23 |
| flutherben | lots of remote branches, using bzr+ssh | 12:23 |
| flutherben | still has been strangely slow | 12:23 |
| LarstiQ | flutherben: ok, would like to have a look at that later then if that's ok | 12:26 |
| * LarstiQ first goes for some grocery shopping etc, bbl | 12:26 | |
| flutherben | yeah, sounds great | 12:26 |
| flutherben | thx | 12:26 |
| DaffyDuck_ | Here's a log illustrating the permissions problem I'm running into: http://pastebin.com/d673e2777 | 13:21 |
| DaffyDuck_ | Is there a solution which does not require running chmod each time a branch is created? | 13:21 |
| DaffyDuck_ | Also, I'm afraid the same problems will arise when a testdev does a "bzr push" for the affected files. | 13:22 |
| bob2 | setgid the dirs? | 13:22 |
| DaffyDuck_ | bob2: Isn't that what the s denotes in rwxrws--- ? | 13:23 |
| bob2 | ah, I'm blind | 13:24 |
| DaffyDuck_ | The s-attribute appear to work for "bzr init", but not "bzr branch". | 13:24 |
| Keybuk | so what's this "2a" format all about? | 13:28 |
| LarstiQ | Keybuk: split inventories and group compression | 13:29 |
| Keybuk | LarstiQ: should I use it? | 13:29 |
| LarstiQ | Keybuk: if you're happy now I think I'd hold off a little while longer | 13:30 |
| LarstiQ | Keybuk: Bazaar is about to switch it's own development branches over | 13:30 |
| LarstiQ | Keybuk: since it's only in 1.16 and 1.17, there are plenty older clients out there that can't read it | 13:31 |
| vxnick | are there any docs about the 2a format yet? | 13:31 |
| Keybuk | LarstiQ: when will Launchpad support the new format? | 13:31 |
| LarstiQ | Keybuk: launchpad the project itself is in 2a, hosted on launchpad, so that should be right now | 13:32 |
| Keybuk | but I can't upgrade my branch | 13:32 |
| Keybuk | something to do with stacked branches? | 13:32 |
| LarstiQ | Keybuk: yeah, stacked branches need to be upgraded first afaik | 13:33 |
| LarstiQ | Keybuk: so that's why I'd recommend waiting for a bit longer, https://bugs.edge.launchpad.net/bzr/+bug/390502 | 13:33 |
| Keybuk | but other people have stacked branches on top of mine | 13:33 |
| LarstiQ | Keybuk: unless you're willing to act as a testbed | 13:33 |
| Keybuk | I'm always willing to help test :-) | 13:33 |
| LarstiQ | Keybuk: the approach outlined in that bug should be updated with the 'stacked branches first', I'll do that when I get back in a bit | 13:35 |
| Keybuk | is there not a way without requiring somebody to upgrade their branch first? | 13:35 |
| Keybuk | seems a bit broken | 13:35 |
| LarstiQ | doing the upgrade dance ourselves will result in documentation for others | 13:35 |
| LarstiQ | Keybuk: has to do with no cross-format stacking iirc | 13:36 |
| LarstiQ | certainly not ideal | 13:36 |
| Keybuk | what if someone created a branch, and then hasn't been contactable since? | 13:36 |
| LarstiQ | Keybuk: LOSA intervention for now I think | 13:36 |
| Keybuk | what's the eventual plan for that? | 13:37 |
| LarstiQ | Keybuk: finding out how to handle things is part of bug 390502 | 13:37 |
| * LarstiQ honestly doesn't know yet | 13:37 | |
| ubottu | Launchpad bug 390502 in bzr "bzr's development should dogfood format 2a" [High,Confirmed] https://launchpad.net/bugs/390502 | 13:40 |
| poelzi | hi | 13:49 |
| poelzi | i have a problem bzr branch lp:pybindgen; cd pybindgen; bzr st | 13:49 |
| |malibu| | Do I need to be using the bazaar server to execute a post_commit plugin? | 13:50 |
| jelmer | hi poelzi | 13:50 |
| poelzi | it causes a hard lockdown on the bzr process | 13:50 |
| poelzi | not even kill -9 helps | 13:50 |
| jelmer | poelzi: I can't reproduce it here, can you do this reproducibly? | 13:50 |
| |malibu| | I'm using bzr+ssh and my post_commit isn't getting fired. It's just a simple os.system("<shell script>") | 13:51 |
| poelzi | on ubuntu jaunty Bazaar (bzr) 1.13.1 it does | 13:51 |
| poelzi | not only here | 13:51 |
| poelzi | how can i enable the trace file ? | 13:52 |
| jelmer | poelzi: bzr should be writing more information by default to ~/.bzr.log | 13:52 |
| jelmer | poelzi: alternatively the output of strace might help to see what's going on exactly | 13:53 |
| poelzi | nothing in the locks yet | 13:55 |
| poelzi | i have a idea | 13:55 |
| LarstiQ | |malibu|: where have you configured the post_commit? | 13:55 |
| |malibu| | ~/.bazaar/plugins | 13:55 |
| |malibu| | It's getting compiled, just not getting fired | 13:57 |
| LarstiQ | |malibu|: so post_commit needs to be enabled for a branch | 13:57 |
| |malibu| | enabled? | 13:58 |
| LarstiQ | |malibu|: you can configure this in ~/.bazaar/locations.conf or .bzr/branch/branch.conf | 13:58 |
| LarstiQ | also, if you're using a smart server, you need to configure it on the server, not locally | 13:58 |
| poelzi | ok. that was it not. could it be that its a lock deadlock somehow ? | 13:58 |
| |malibu| | I'm not using a server.. just bzr+ssh | 13:59 |
| |malibu| | I will look up branch.conf. Thanks | 13:59 |
| LarstiQ | |malibu|: you are using the smartserver with bzr+ssh | 14:00 |
| |malibu| | ah | 14:00 |
| quicksilver | does the launchpad code have a repo browser for bzr repos? Or do they use loggerhead? | 14:02 |
| jelmer | quicksilver: they use loggerhead | 14:02 |
| quicksilver | jelmer: thanks. | 14:02 |
| jelmer | luks: I've pushed some improvements to your branch to lp:~bzr-svn/bzr-svn/send | 14:15 |
| jelmer | luks: in particular, using the 'svn' send format by default when submitting to a svn branch | 14:15 |
| james_w | ooh | 14:16 |
| james_w | what's the 'svn' send format? | 14:16 |
| homy | Can I just rename or move a file to another subdirectory normally? | 14:18 |
| jelmer | james_w: basically the format that "svn diff" would generate (including svn revision numbers) as part of 'bzr send' | 14:20 |
| james_w | cool | 14:20 |
| jelmer | james_w: it should make cooperation with upstreams that are using svn easier, as they wouldn't be interested in bzr bundles with bzr metadata | 14:20 |
| LarstiQ | homy: `bzr mv file subdir/` sure | 14:21 |
| LarstiQ | jelmer: will that roundtrip? | 14:21 |
| LarstiQ | I'm guessing no, and that can be fine | 14:21 |
| jelmer | james_w: the idea is also to support something similar for 'git am' style patches, but for that 'bzr send' needs to support multiple attachments first | 14:21 |
| jelmer | LarstiQ: no, it won't roundtrip (unless there's some way to create svn revision properties from a svn diff that I'm not aware of) | 14:22 |
| james_w | maybe we could look at that next week | 14:22 |
| luks | LarstiQ: I don't think svn has any builtin tool to apply some patches | 14:23 |
| luks | LarstiQ: this is mainly interesting for projects like Review Board | 14:23 |
| LarstiQ | luks: I saw you coded towards that, how does it work? | 14:23 |
| homy | LarstiQ: I meant can I just move the file normally without bazaar or do I need to use bzr mv? | 14:23 |
| james_w | homy: you need to tell bzr about it at some point | 14:24 |
| james_w | you can use bzr mv --after to do it after you move | 14:24 |
| luks | LarstiQ: well, when working with svn-configured review board, it expects you to submit 'svn diff' patches. it parses the patch and looks up the revisions in the repository | 14:24 |
| james_w | or bzr mv --auto to have it guess | 14:24 |
| LarstiQ | homy: what james_w said, or try `bzr mv --auto` | 14:24 |
| luks | and this allows me to generate such patches from bzr | 14:25 |
| homy | ok. thanks. | 14:25 |
| LarstiQ | luks: hoo boy | 14:25 |
| LarstiQ | luks: and then you get a green light and can commit it? | 14:25 |
| luks | yes | 14:25 |
| pfctdayelise | hi, if I'm using bzr for a web app (Python), is there a way I can get the current bzr revision and insert/display it in my web app? | 14:25 |
| LarstiQ | luks: at which point it may no longer apply? | 14:25 |
| jelmer | flutherben: from bzrlib.branch import Branch; b = Branch.open(path_to_branch); print b.revno() | 14:25 |
| luks | LarstiQ: what no longer applies? | 14:25 |
| LarstiQ | luks: the patch | 14:26 |
| luks | oh, well, yes | 14:26 |
| james_w | pfctdayelise: have a look at "bzr version-info" | 14:26 |
| LarstiQ | luks: or alternatively, `svn update` might give conflicts | 14:26 |
| james_w | pfctdayelise: or something like jelmer suggests if you are in python | 14:26 |
| luks | LarstiQ: but you have the same problem with bzr | 14:26 |
| LarstiQ | luks: I'm sure it is an improvement in workflow | 14:26 |
| luks | LarstiQ: you review a patch, commit something upstream and the patch might no longer cleanly merge | 14:26 |
| LarstiQ | luks: ish, it is much easier to work with different branches | 14:26 |
| LarstiQ | luks: right | 14:26 |
| pfctdayelise | jelmer, james_w : thanks | 14:27 |
| jelmer | flsorry, no, for pfctdayelise | 14:39 |
| jelmer | larah, awesome | 14:39 |
| hno | Hmm.. any suggestions on how to recover an old dev repository? bzr 1.16.1 says bzr: ERROR: Unknown repository format: 'Bazaar development format 2 (needs bzr.dev from before 1.8)\n'. | 14:44 |
| hno | I guess I need to downgrade to 1.7 or so, but what should I do next? | 14:44 |
| * LarstiQ blinks | 14:44 | |
| LarstiQ | hno: that's new to me | 14:45 |
| LarstiQ | hno: is there a public copy of the branch? | 14:45 |
| hno | Not at the moment, and it's rather big to move around... (ca 500MB) | 14:46 |
| LarstiQ | right | 14:46 |
| LarstiQ | hno: speculating, if you have 1.7, I'd upgrade the branch to a newer format 1.7 can upgrade to and 1.16.1 can read from | 14:47 |
| LarstiQ | hno: I suppose that would be 0.92 | 14:47 |
| LarstiQ | hno: but I'm not sure what the dev format 2 _is_, so perhaps we'll run into some upgrade path issues | 14:48 |
| hno | Not sure either. But the branch isn't using any excotic features of bzr. I think it was "upgraded" to the dev format at the time for performance reasons only. | 14:52 |
| hno | Hmm.. now I am truly confused. Exact same error with bzr 1.7. | 14:55 |
| hno | .bzr/branch/format says "Bazaar Branch Format 7 (needs bzr 1.6)". .bzr/repository/format says "Bazaar development format 2 (needs bzr.dev from before 1.8)" | 14:58 |
| LarstiQ | hno: oh hmm, 'bzr.dev' from before 1.8 | 14:59 |
| LarstiQ | hno: did you use a released bzr or bzr.dev to do the upgrade with? | 15:00 |
| LarstiQ | hno: it might mean the branch is in a format that never got released | 15:00 |
| cgratecos | hi there, does someone know if there's some french translators to the bazaar project ? | 15:00 |
| hno | Released bzr I think. | 15:00 |
| LarstiQ | hno: is the bzr.dev string literally in .bzr/repository/format ? | 15:01 |
| hno | Those strings are the literal contents of the files. | 15:01 |
| LarstiQ | cgratecos: there are French speaker developers, translation wise I think bzr-explorer sees the most action | 15:02 |
| LarstiQ | cgratecos: though the documentation of bzr might be translated to French as well, there is a Russian translation at least | 15:02 |
| LarstiQ | hno: ok | 15:02 |
| LarstiQ | hno: in that case I think it is a reasonable bet to try a bzr.dev version then | 15:02 |
| LarstiQ | hno: let me look up which revision | 15:02 |
| jelmer | I think there also was work happening on a spanish translation | 15:03 |
| LarstiQ | hno: r4265 disabled development2 at least | 15:03 |
| hno | Checking the versions I have packaged... may have been 1.6.1rc2. | 15:04 |
| hno | Argh.. need newer bzr to access launchpad... :) | 15:05 |
| lifeless | hno: bzr dump-btree .bzr/repository/pack-names | 15:05 |
| lifeless | hno: if that works, its really a 1.9 format and you can just edit the format string to match | 15:06 |
| lifeless | if it fails, its a 1.6 format, and <ditto> | 15:06 |
| hno | $ bzr dump-btree .bzr/repository/pack-names | 15:07 |
| hno | (('29e78c8e7bb53e72a3dc28d4e341774f',), '317 350 3007752 72') | 15:07 |
| hno | do that make sense? | 15:07 |
| lifeless | yes | 15:07 |
| lifeless | its a btree using format | 15:07 |
| cgratecos | if you want some help for french translation !! (i didn't found any mailing list for translating !!) | 15:07 |
| lifeless | do this: | 15:07 |
| lifeless | bzr init-repo /tmp/foo --1.9 | 15:07 |
| lifeless | cp /tmp/foo/.bzr/repository/format .bzr/repository/format | 15:08 |
| hno | Thanks! | 15:10 |
| lifeless | np | 15:10 |
| lifeless | good night | 15:10 |
| lifeless | jelmer: if you could do that review... ;) | 15:11 |
| LarstiQ | cgratecos: which part are you interested in translating? | 15:11 |
| jelmer | lifeless: Sorry, got distracted | 15:11 |
| jelmer | lifeless: I'm planning to do it later today though | 15:11 |
| lifeless | thanks | 15:12 |
| LarstiQ | jelmer: thanks for the 1.17 upload! | 15:12 |
| jelmer | what was the ftp-like tool based on bzr transports again? | 15:13 |
| LarstiQ | jelmer: lp:hitchhiker | 15:13 |
| jelmer | LarstiQ: thanks | 15:13 |
| cgratecos | LartiQ: i'm interested by making french people use bzr caus i like it !! and i didn't found any french translation on your site !! so tell me what to translate i'll do it !! | 15:13 |
| LarstiQ | cgratecos: if you have a copy of bzr.dev, have a look at the doc/ directory | 15:14 |
| LarstiQ | cgratecos: specifically doc/en for english, doc/es for spanish and doc/ru for Russian | 15:15 |
| LarstiQ | cgratecos: you could start a doc/fr | 15:15 |
| cgratecos | LartiQ: let's go !! | 15:15 |
| cgratecos | LarstiQ: it's look easy to do !! is there someone allready working on french translation ? we could share the work and i hate to make something that have allready been made !! | 15:26 |
| LarstiQ | cgratecos: I'm not aware of that, but you could search the list archives | 15:28 |
| LarstiQ | cgratecos: 'google site:lists.canonical.com bazaar french' I guess | 15:29 |
| LarstiQ | cgratecos: however, you could try getting in touch with the translators for bzr-explorer | 15:29 |
| LarstiQ | cgratecos: https://translations.edge.launchpad.net/bzr-explorer | 15:30 |
| sender | cgratecos: what's your question? | 15:30 |
| cgratecos | sender: i want to translate the bazaar site and the documentation in french ! | 15:31 |
| cgratecos | LarstiQ: thanks | 15:31 |
| LarstiQ | cgratecos: ah, for the site I recall there might be prior work | 15:32 |
| sender | cgratecos: great! I almost finished the dutch translation for bzr-explorer last night, it's quite easy to do | 15:32 |
| sender | cgratecos: create a login on launchpad and set your 'prefered language' to include french | 15:32 |
| * LarstiQ quickly jumps on the Dutch bandwagon | 15:33 | |
| sender | cgratecos: now you can edit the translation here: https://translations.launchpad.net/bzr-explorer/trunk/+pots/explorer | 15:33 |
| sender | LarstiQ: :) | 15:33 |
| Kinnison | jelmer: Is it a known side-effect that translating from pack-0.92 to 2a will add a file-id ? (is that the 'rich root' ?) | 15:34 |
| LarstiQ | Kinnison: 2a is a rich-root format (finally!), so that sounds plausible | 15:35 |
| cgratecos | sender: i create my login and i'll do the work (there's allready a lot of work done !!) | 15:35 |
| Kinnison | LarstiQ: cool | 15:36 |
| sender | cgratecos: yes, still 88 untranslated to go.. those are the hard ones probably, good luck ;) | 15:36 |
| * Kinnison is playing with his branches to check they all translate | 15:37 | |
| Kinnison | the one with umpteen arch branches merged into one, plus several other branches merged with the 0..-1 trick seems to play ball nicely | 15:37 |
| sender | LarstiQ: did you do some dutch translations on lp? | 15:39 |
| LarstiQ | sender: not yet | 15:39 |
| sender | LarstiQ: ah ok thought I'd used some translation suggestions from a certain Lars ;) What's your opinion on keywords like branch, commit, update, merge, etc.. translate to NL or not? | 15:40 |
| LarstiQ | sender: I'm very very biased on that topic. My opinion is to not translate them, but then, everything I use is in English so I'm not the exact target demographic. | 15:41 |
| cgratecos | sender: i'm working on the french translation on launchpad, my nickname is gtechnix, i'll go back home in 10 minutes but on it tonight | 15:44 |
| cgratecos | oups | 15:44 |
| cgratecos | i'll work on it tonight | 15:44 |
| sender | cgratecos: great, take your time ;) thanx! | 15:44 |
| hmeland_ | sender: For documentation I'd think it could make sense to differentiate between the command and the concept (but I speak NO rather than NL, and I'm also happy using everything in English). | 15:45 |
| sender | LarstiQ: same here... i never like changed shortcuts b/c of localization and especially the Dutch functionnames in excel :/ | 15:47 |
| sender | hmeland_: I think we agree.. in documentation the concept should be explained using the native language (just like help and statusbar text in the app) and the keyword itself can better stay in english for sake of unanimity | 15:49 |
| LarstiQ | sender: translating the API was a really stupid decision for Excel | 15:49 |
| sender | LarstiQ: I never saw it in any other app/language.. hope that that flaw never occured somewhere outside MS hq ;) | 15:55 |
| Kinnison | jelmer: when you file those bugs, please let me know so I can subscribe to them | 16:11 |
| jelmer | Kinnison: will do | 16:12 |
| mickstephenson | Hi, can someone help, I'm trying to checkout some code from launchpad and I'm getting this error "Permission denied (publickey)." It's only occurred since i entered my launchpad login to bzr | 16:15 |
| Kinnison | Is your SSH key registered with launchpad and do you have the key present? | 16:16 |
| mickstephenson | I think the key I have on bzr is from another computer, I thought this would only be important when committing code? this is basically just an anonymous checkout. | 16:18 |
| Kinnison | Not GPG key, SSH key | 16:19 |
| Kinnison | once you give bzr your LP login, it will try to use bzr+ssh instead of http to fetch content | 16:19 |
| mickstephenson | oh ok, i'll upload my key anyway, thanks | 16:20 |
| Kinnison | No problem | 16:20 |
| Kinnison | You'll want your key on launchpad if you want to push branches to it anyway | 16:20 |
| Kinnison | so it's a handy thing to do | 16:20 |
| garyvdm | mickstephenson: You can still download using http with out a ssh key | 16:24 |
| garyvdm | It will be slower though | 16:24 |
| mickstephenson | I think I will need to, it must take some time after pasting the key inot launchpad that it propagates to bzr | 16:25 |
| mozmck_work | Hi, If I have deleted versioned files from my working directory, what do I need to do to tell bzr they are gone? | 16:28 |
| Kinnison | it will notice, type 'bzr status' and check | 16:29 |
| mozmck_work | ah, so a commit will do it all? | 16:30 |
| Kinnison | it does for me. But I make no guarantees :-) | 16:30 |
| mozmck_work | good! | 16:30 |
| igc | night all | 16:46 |
| wadesworld | hi guys, looking for some help importing a CVS repository....I have the actual repository (not a checkout) - I *think* I can use bzr cvsps-import....correct? | 17:01 |
| LarstiQ | wadesworld: I think so, though no experience with it | 17:01 |
| awmcclain | Well, hrmph. Updating my local repository is failing miserably | 17:17 |
| awmcclain | starting repository conversion | 17:17 |
| awmcclain | Python(2806) malloc: *** mmap(size=20480) failed (error code=12)ring revisions: | 17:17 |
| awmcclain | *** error: can't allocate region | 17:17 |
| awmcclain | *** set a breakpoint in malloc_error_break to debug | 17:17 |
| awmcclain | bzr: ERROR: Must end write group before releasing write lock on CHKInventoryRepository('file:///Users/andrew/clownfish/panda-repo/.bzr/repository/') | 17:17 |
| LarstiQ | awmcclain: woo | 17:18 |
| LarstiQ | awmcclain: what command is that? | 17:19 |
| LarstiQ | awmcclain: just `bzr upgrade`? | 17:19 |
| awmcclain | --1a | 17:19 |
| awmcclain | eep | 17:19 |
| awmcclain | sorry | 17:19 |
| awmcclain | bzr upgrade --2a | 17:19 |
| LarstiQ | right | 17:21 |
| LarstiQ | awmcclain: with bzr 1.17? | 17:22 |
| awmcclain | correct | 17:26 |
| === kiko is now known as kiko-fud | ||
| agrippa | heyas | 17:35 |
| agrippa | Trying to get a diff tool that will work with bzr on OS X. Any suggestions? | 17:35 |
| awmcclain | agrippa: opendiff? | 17:47 |
| awmcclain | soo...any suggestions about how to upgrade my repo? | 17:48 |
| wadesworld | agrippa, I think I got it set up to use FileMerge at one point | 17:48 |
| wadesworld | but it was a long time ago, and I don't remember the specifics | 17:49 |
| awmcclain | wadesworld: Yeah, i think if you install filemerge and then alias opendiff to it... or you may not even need to | 17:49 |
| awmcclain | if i run bzr diff --using=opendiff it opens filemerge | 17:49 |
| agrippa | It just seems to send it to stdout for me if I do that | 17:53 |
| agrippa | But I did find the FileMerge utility, so that's good. I don't need to go and purchase Changes now. | 17:53 |
| awmcclain | what does man opendiff give you? | 17:54 |
| agrippa | It describes opendiff as "a command line utility that provides a convenient way to launch the FileMerge application from Terminal..." | 17:56 |
| agrippa | OK, nice, it does launch FileMerge when I use it, just doesn't seem to want to play nice with bzr | 17:57 |
| awmcclain | bzr diff --using=opendiff doesn't work? | 17:57 |
| agrippa | Yeah, just exits immediately | 17:58 |
| agrippa | When I do something like "bzr -r1..10 --using=opendiff" it just sends the diff to the terminal instead of opening FileMerge | 17:58 |
| agrippa | erm, bzr diff -r1..10 --using=opendiff rather | 17:59 |
| awmcclain | hrm | 17:59 |
| awmcclain | *shrug* | 17:59 |
| agrippa | Oh, maybe I need the difftools plugin installed | 18:00 |
| agrippa | Going to try that | 18:00 |
| agrippa | OK, that worked. | 18:07 |
| malibu | Hello folks. | 18:19 |
| malibu | A question about 'hooks' | 18:20 |
| malibu | I cannot find any documentation on enabling them for the smartserver | 18:20 |
| malibu | Where can I find something like that? | 18:20 |
| * LarstiQ pipes back up | 18:20 | |
| LarstiQ | malibu: can you describe exactly how you configured the hook, and how you are accessing it? | 18:21 |
| LarstiQ | malibu: for me, if I use bzr+ssh://source/srv/bzr/foo/bar, I use [/srv/bzr] in source:~user/.bazaar/locations.conf for a pattern | 18:22 |
| malibu | I put a commit_plugin.py into ~/.bazaar/plugins | 18:23 |
| LarstiQ | malibu: or in earlier versions, that might be chroot-*:///srv/bzr/ | 18:23 |
| LarstiQ | malibu: right, remotehost:~/.bazaar/plugins ? | 18:23 |
| malibu | It uses the install_named_hook method to register a function | 18:24 |
| malibu | yes, on the repository host | 18:24 |
| malibu | basically the function just attempts to call a shell script | 18:25 |
| malibu | using import os, os.system("script") | 18:25 |
| malibu | The hook compiles fine, | 18:25 |
| malibu | it shows up in bzr hooks | 18:25 |
| malibu | ..but it does not fire | 18:26 |
| malibu | I need it in ~/.bazaar/locations.conf you say? | 18:26 |
| LarstiQ | malibu: right | 18:26 |
| LarstiQ | malibu: well, normally you'd have to configure a hook to be run for a branch. If you don't, it won't fire. | 18:27 |
| LarstiQ | but then again, if you have written your own plugin, you could be doing things differently | 18:28 |
| LarstiQ | malibu: can you share your plugin? | 18:28 |
| malibu | sure | 18:28 |
| malibu | is there a bzr pastebin? | 18:28 |
| LarstiQ | malibu: any pastebin will do if it is just one file | 18:28 |
| malibu | http://pastebin.org/3597 | 18:31 |
| malibu | I just took the sample from the docs and modified it a bit | 18:31 |
| malibu | thx | 18:31 |
| LarstiQ | not too complicated :) | 18:32 |
| * LarstiQ tries it | 18:32 | |
| malibu | lol, sure you can handle it | 18:32 |
| LarstiQ | malibu: what version of bzr are you using? | 18:34 |
| GaryvdM | malibu: post_commit will never be fired on the server. You should rather hook onto tip_change | 18:34 |
| GaryvdM | I think it is tip_change, but I'm not sure - so look for something like that. | 18:35 |
| malibu | tip_change? what does that mean? | 18:35 |
| LarstiQ | oh shoot, I forgot about that | 18:36 |
| malibu | 1.13.1 | 18:36 |
| LarstiQ | malibu: the tip of a branch is the most recent revision | 18:36 |
| GaryvdM | malibu: It's called when the latest revision (tip) of a branch | 18:36 |
| malibu | ah | 18:36 |
| GaryvdM | changes | 18:36 |
| GaryvdM | So post_commit will only get called if you do bzr commit | 18:36 |
| GaryvdM | but tip_change will get called if you commit, push, pull etc... | 18:37 |
| LarstiQ | GaryvdM: which with a checkout could happen against bzr+ssh, but yes | 18:37 |
| malibu | But it gets called on the client side | 18:37 |
| LarstiQ | malibu: your post_commit hook gets called clientside? Yes, that underlines what GaryvdM said and I forgot about | 18:37 |
| malibu | Well I don't know if it is getting called client side, there is no shell script client side | 18:38 |
| malibu | But I was trying to understand what GaryvdM was saying by reiterating | 18:38 |
| malibu | trying it now | 18:42 |
| GaryvdM | malibu: The correct name of the hook is "post_tip_change" | 18:53 |
| malibu | ahhh.. shoot | 18:53 |
| malibu | thnaks | 18:53 |
| malibu | was just going to bitch about it still not working! | 18:53 |
| malibu | but you are gone now o it don't matter! | 18:54 |
| malibu | ah there you are | 18:54 |
| siliu | Does anyone know why I can not use bze qlog? | 18:54 |
| LarstiQ | siliu: not without more information :P | 18:54 |
| GaryvdM | malibu: What did you say when I was gone? | 18:54 |
| malibu | just thanks, and that I was just coming in to bitch that it still wasn't working | 18:55 |
| malibu | but I used tip_change | 18:55 |
| GaryvdM | siliu: What does it say when you try run bzr qlog? | 18:55 |
| malibu | shoot, still didn't work | 19:00 |
| GaryvdM | malibu: I just figured out - you can get the documentation on hooks by running bzr help hooks | 19:01 |
| GaryvdM | Sorry - post_change_branch_tip | 19:03 |
| LarstiQ | malibu: which hooks documentation were you reading earlier? | 19:03 |
| siliu | GaryvdM, I got the message bzr: ERROR: unknown command "qlog" | 19:07 |
| LarstiQ | ok, so I was confused by the bzr-email plugin also installing a post_change_branch_tip hook | 19:08 |
| GaryvdM | siliu: qlog is apart of the qbzr plugin. This is probably not installed. | 19:08 |
| LarstiQ | siliu: do you have qbzr installed? | 19:08 |
| LarstiQ | siliu: it should be in `bzr plugins` output | 19:08 |
| GaryvdM | siliu: Windows or other os? | 19:09 |
| malibu | I fond 'how to make a plugin' on the wiki | 19:09 |
| malibu | Also I was reading the Bazaar manual | 19:09 |
| malibu | but there wasn't very much detail | 19:09 |
| siliu | fedora 10 | 19:10 |
| malibu | GaryvdM no prob, will try that | 19:10 |
| GaryvdM | siliu: I don't thing that there are any rpm for qbzr, so you are going to have to install it manualy. | 19:10 |
| LarstiQ | malibu: if you can point me to the exact locations I'll see about changing them to point at `bzr help hooks` | 19:11 |
| GaryvdM | siliu: I lie. There do seem to be rmps - see http://rpm.pbone.net/index.php3/stat/4/idpl/12544874/com/qbzr-0.11-1mdv2010.0.noarch.rpm.html | 19:12 |
| GaryvdM | Thats for 0.11 - Latest release is 0.12 | 19:13 |
| malibu | LastiQ: hard for me to do it now, slow vnc connection. Will look for you later | 19:14 |
| LarstiQ | malibu: ok | 19:15 |
| LarstiQ | malibu: http://bazaar-vcs.org/WritingPlugins is a bit old | 19:15 |
| * LarstiQ updates | 19:17 | |
| siliu_openmedian | thanks GaryvdM I will try that | 19:20 |
| === kiko-fud is now known as kiko | ||
| === garyvdm changed the topic of #bzr to: Launchpad's now open source! | Bazaar version control system | 1.17 released 20th July, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | ||
| garyvdm | twas released yesterday... | 19:55 |
| LarstiQ | point, point :) | 19:59 |
| malibu | holy cow! My post_change_branch_tip hook worked! | 20:20 |
| LarstiQ | woo! | 20:21 |
| malibu | Of course, I'm not sure why creating one empty text file caused it to do a 'writing local files' of 10Gb..... | 20:29 |
| LarstiQ | malibu: heuh? | 20:36 |
| jfroy | Has the 2a migration document been published? | 20:48 |
| jfroy | Specifically the steps to migrate branches on Launchpad to 2a without hosing everything because of stacking. | 20:49 |
| LarstiQ | jfroy: working on it, https://bugs.edge.launchpad.net/bzr/+bug/390502 | 20:49 |
| ubottu | Ubuntu bug 390502 in bzr "bzr's development should dogfood format 2a" [High,Confirmed] | 20:49 |
| jfroy | That seems specific to bzr? | 20:51 |
| jfroy | I vaguely recall a 2a migration document was being prepared, I'm just not sure where the draft is. | 20:51 |
| LarstiQ | jfroy: doc/en/upgrade-guide/ ? | 20:55 |
| jfroy | mm | 20:57 |
| jfroy | I see | 20:58 |
| jfroy | it's not in the 1.17 distro. | 20:58 |
| LarstiQ | nor in the 1.17 branch | 20:59 |
| LarstiQ | jfroy: yeah the bug is about dogfooding, you can upgrade now (with the bzr.dev document) or you could wait a bit for bzr.dev to go through the process | 21:00 |
| jfroy | I see | 21:03 |
| jfroy | the process is mostly to sidestep the entire issue | 21:03 |
| jfroy | by keeping the old format trunk around (and thus not breaking any stacked branch) | 21:04 |
| jfroy | And blessing a new 2a format branch as the development focus moving forward | 21:04 |
| LarstiQ | right | 21:04 |
| LarstiQ | I'm not sure I'm entirely happy with that arrangement | 21:04 |
| jfroy | neither am I | 21:05 |
| jfroy | seems messy | 21:05 |
| LarstiQ | having people's stacked brances upgraded to 2a automatically is less ideal though :/ | 21:06 |
| jfroy | :/ | 21:07 |
| jfroy | is there going to be a conflict on the name of the branch, I wonder | 21:08 |
| jfroy | not that it matters much in so far as the development focus branch is aliased when using lp: | 21:08 |
| SamB | stacked branches will break? | 21:08 |
| jfroy | they won't, not if you keep the old development focus around | 21:09 |
| SamB | I mean, would | 21:09 |
| SamB | if you upgraded what they were stacked on to 2a in-place? | 21:09 |
| jfroy | one worry is that because bzr has no way to mark a branch as closed, people could still be operating on the old trunk... | 21:09 |
| SamB | why? | 21:09 |
| jfroy | might because a nightmare where you have 2 development focus diverging | 21:09 |
| SamB | jfroy: I has a way | 21:09 |
| SamB | chmod -w | 21:09 |
| jfroy | how do you do that on Launchpad hosted branches, exactly :p | 21:10 |
| SamB | you get a sysadmin-priviliged person to do it | 21:10 |
| jfroy | fair enough | 21:10 |
| SamB | well, that only helps for bzr.dev | 21:10 |
| SamB | but you could presumably automate that | 21:11 |
| SamB | thereby adding such a way to launchpad ;-) | 21:11 |
| jfroy | feels like a hack-ishy way though | 21:11 |
| SamB | what worries *me* is how do you get people to stop pulling from that branch? | 21:11 |
| jfroy | may be nicer to have a formal way to close a branch, perhaps providing a "use this one instead" message of sort. | 21:11 |
| SamB | an MOTD mechanism might not be unwelcome | 21:12 |
| jfroy | which bzr could display on push, pull and branch | 21:12 |
| jfroy | *files a bug* | 21:12 |
| SamB | darcs has such a thing for pulls/branches, at least | 21:12 |
| jfroy | so does hg | 21:12 |
| SamB | dunno about git | 21:12 |
| SamB | ... why the heck is bzr in the "devel" section? | 21:14 |
| SamB | shouldn't it be in "vcs" instead? | 21:15 |
| jfroy | https://bugs.edge.launchpad.net/bzr/+bug/403203 | 21:16 |
| ubottu | Ubuntu bug 403203 in bzr "A a "close branch" command with optional message" [Undecided,New] | 21:17 |
| jfroy | lol double As | 21:17 |
| jfroy | fixed >.> (eternal thanks for inline editing on Launchpad) | 21:17 |
| SamB | jfroy: a mutable "message of the day" would be sufficient | 21:17 |
| jfroy | not strong enough IMO | 21:18 |
| jfroy | It would be preferable for bzr to error out of commands like branch, push and pull. | 21:18 |
| jfroy | Which requires additional state. | 21:18 |
| LarstiQ | SamB: it is in "vcs" in Debian afaik | 21:18 |
| SamB | LarstiQ: hmm. | 21:18 |
| LarstiQ | SamB: so where are you seeing this? | 21:19 |
| SamB | apparantly aptitude picks one of the sections at random? | 21:19 |
| SamB | or ... dunno | 21:19 |
| SamB | all of these available versions seem to be in "vcs" | 21:20 |
| SamB | but the listing for bzr was in "devel" in aptitude's UI | 21:20 |
| SamB | oh, wait | 21:21 |
| SamB | Section: devel | 21:21 |
| SamB | Version: 1.17+4556+119 | 21:21 |
| LarstiQ | SamB: in unstable? | 21:22 |
| SamB | LarstiQ: so are you saying it's in "vcs" for Debian but "devel" for Ubuntu? | 21:22 |
| SamB | no, that's the PPA | 21:22 |
| LarstiQ | SamB: PPA or? | 21:22 |
| LarstiQ | ok | 21:22 |
| LarstiQ | SamB: it is devel for the PPA I think | 21:22 |
| SamB | still odd | 21:22 |
| LarstiQ | SamB: it _used_ to be devel in Debian too | 21:22 |
| SamB | yeah, I thought that might be the case | 21:23 |
| * LarstiQ checks the changelog | 21:23 | |
| SamB | I wasn't even assuming that it wasn't supposed to be now | 21:23 |
| SamB | ... so what's the new URL for bzr.dev? | 21:24 |
| LarstiQ | SamB: no change yet | 21:24 |
| LarstiQ | SamB: hmm, http://packages.ubuntu.com/search?keywords=bzr still has it at devel | 21:25 |
| * SamB wonders where the branch for the ubuntu packaging is | 21:26 | |
| SamB | oh, all the plugins too? | 21:26 |
| SamB | wow this page looks odd to me: http://packages.ubuntu.com/karmic/bzr | 21:27 |
| SamB | it's like someone took packages.debian.org and tried to theme it | 21:28 |
| SamB | ... and took out some of the links :-( | 21:29 |
| SamB | why no "ubuntu package tracking system"? | 21:29 |
| LarstiQ | I don't know | 21:29 |
| LarstiQ | I do know that when packages.ubuntu.com got set up it was run by the same admin as packages.debian.org | 21:30 |
| LarstiQ | same code too | 21:30 |
| SamB | LarstiQ: well I can *see* that it's largely the same code | 21:30 |
| LarstiQ | :) | 21:30 |
| SamB | jelmer: where it says "Debian Package Source Repository (VCS: bzr)\n http://bzr.debian.org/pkg-bazaar/bzr/unstable" at the bottom of http://packages.ubuntu.com/source/karmic/bzr, does it actually mean that's where the ubuntu package source comes from too? | 21:32 |
| SamB | I mean, should it say "Ubuntu Package Source Repository" there, or? | 21:33 |
| LarstiQ | SamB: I think that is parsed from Vcs-Bzr: http://bzr.debian.org/pkg-bazaar/bzr/unstable | 21:36 |
| LarstiQ | SamB: and for Ubuntu the process is different, so there is no equivalent header, the Debian is left intact | 21:37 |
| SamB | LarstiQ: how does it work for Ubuntu? | 21:37 |
| * LarstiQ speculates further | 21:38 | |
| LarstiQ | SamB: judging from a james_w dent, package branches on Launchpad | 21:38 |
| SamB | LarstiQ: anyway, I wasn't sure about that myself which is why I decided to ask the one whose name is on all the changelog entries for both projects that I see ;-) | 21:39 |
| LarstiQ | you mean jelmer? :) | 21:39 |
| LarstiQ | SamB: afaik bzr is just synced into ubuntu from debian most times | 21:40 |
| james_w | SamB: it's hit and miss whether that is where the Ubuntu code is stored | 21:40 |
| james_w | in bzr's case it is correct | 21:40 |
| SamB | LarstiQ: yeah | 21:40 |
| SamB | anyway -- how does one find these "package branches on launchpad"? | 21:41 |
| SamB | what exactly is a "remap"? | 22:09 |
| * SamB wonders why bzr repacks packs in a log_10 fashion | 22:24 | |
| lifeless | SamB: latency | 22:25 |
| lifeless | if you mean why log10 rather than logn or log2, that is mostly arbitrary | 22:26 |
| SamB | is it going to insist on repacking when there are 10000 revisions in the repository? | 22:26 |
| lifeless | yes | 22:26 |
| SamB | ouch | 22:26 |
| lifeless | not really, that doesn't happen often :) | 22:26 |
| SamB | I don't know if my computer can handle it though | 22:27 |
| lifeless | its expoential backoff | 22:27 |
| SamB | how much does it cost to do a repack, RAM-wise? | 22:27 |
| lifeless | depends on format and how unpacked it is | 22:27 |
| lifeless | a 2a format recompresses | 22:27 |
| lifeless | 1.9 and before just shuffle data around to consolidate packs | 22:28 |
| SamB | how much redeltaing does it do ? | 22:28 |
| lifeless | in 2a, a lot | 22:28 |
| lifeless | its pretty fast though | 22:28 |
| SamB | what computational complexity ? | 22:28 |
| lifeless | and memory wise, if you managed to commit you will be able to pack | 22:28 |
| SamB | oh. | 22:28 |
| LarstiQ | bar bugs | 22:28 |
| SamB | okay. | 22:29 |
| lifeless | [with some fuzz] | 22:29 |
| SamB | ... oh, while we speak of RAM, I saw a thread in the bzr list about a memory profiling tool. do you know the current URL of that tool? | 22:29 |
| * SamB forgot even the name, but doesn't remember the URL being too informative ... | 22:30 | |
| lifeless | its in jams +junk | 22:30 |
| lifeless | pymemdump | 22:30 |
| SamB | and his LP id is jam? | 22:30 |
| lifeless | jameinel | 22:30 |
| SamB | thanks | 22:30 |
| jam | SamB: lp:~jameinel/+junk/py_memory_dump IIRC | 22:31 |
| jam | hi lifeless | 22:31 |
| lifeless | hi jam | 22:31 |
| SamB | jam: why no project? | 22:31 |
| jam | SamB: I never came up with a nicer name for it | 22:31 |
| SamB | the name seems an adequate description of how it works | 22:32 |
| jam | I was hoping to have something fun | 22:32 |
| LarstiQ | jam: was lp:~ian-clatworthy/bzr/sphinx-userdocs/ the 2a upgrade docs you had in mind? | 22:32 |
| LarstiQ | jam: ehm, doc/en/upgrade-guide/ in bzr.dev | 22:32 |
| jam | LarstiQ: I don't think it would be under "sphinx" | 22:32 |
| jam | LarstiQ: upgrade-guide sounds about right | 22:32 |
| * SamB hands jam a stack of Monty Python DVDs and tells him to knock himself out, then | 22:32 | |
| jam | data_migration | 22:33 |
| garyvdm | jam: how dose that compare to heapy? | 22:33 |
| jam | LarstiQ: data_migration.txt subheading Migrating Branches on Launchpad | 22:33 |
| jam | garyvdm: The #1 difference is that it dumps the information about memory consumption to disk with a *very* lightweight process | 22:33 |
| IRConan | hi... I'm trying to import an hg repo into bazaar but I get this error: http://pastebin.com/m43e0952e | 22:34 |
| jam | so if you interrupt your 1GB consumption, it can actually work | 22:34 |
| IRConan | anyone know what's going on? | 22:34 |
| jam | and then you run a separate bit to analyze it | 22:34 |
| garyvdm | jam: I see | 22:34 |
| jam | also, it works on windows, mac, 64 bit, etc | 22:34 |
| jam | garyvdm: heapy liked to crash or just not compile for me | 22:34 |
| jam | also, by dumping to disk, you can do your own data mining a bit easier | 22:34 |
| jam | like 'grep' is a surprisingly useful memory debugging tool :) | 22:35 |
| LarstiQ | jam: I read that, it seems suboptimal, though it has the merit of keeping things working | 22:35 |
| jam | LarstiQ: what would you consider "more optimal" ? | 22:35 |
| LarstiQ | jam: cross-format stacking | 22:35 |
| jam | given that you break a stacked branch if you upgrade the source underneath it | 22:35 |
| jam | LarstiQ: if you want to implement that, feel more than welcome | 22:35 |
| garyvdm | jam: and cause it writes to disk, you can look at someone else's dump | 22:35 |
| jam | garyvdm: sure | 22:35 |
| jam | just be aware, the dumps are pretty big | 22:35 |
| jam | I went with JSON, and it ends up at least the same size as in ram | 22:36 |
| garyvdm | Ok | 22:36 |
| jam | but bzip2 works well | 22:36 |
| * SamB thinks he would prefer the new lzma format | 22:36 | |
| LarstiQ | jam: it is not the pragmatic move no. I'll mull things over tonight (bedtime now) and get things rolling again tomorrow | 22:36 |
| SamB | (why new? because they smartened up and added magic bytes, that's why!) | 22:36 |
| garyvdm | jam: vila says that qlog mysqlbranch can use up to 2gb - but I can't reproduce, and have only seen max 400mb. | 22:38 |
| LarstiQ | night | 22:38 |
| garyvdm | maybe I can use that to debug | 22:38 |
| jam | garyvdm: might be a 64-bit vs 32-bit thing? | 22:39 |
| garyvdm | Yes - vila did mention that. | 22:39 |
| jam | given that 90% of objects double in size on 64-bit | 22:39 |
| lifeless | poor irconan, got no answers | 22:40 |
| SamB | jam: that doesn't explain 400mb -> 2gb | 22:40 |
| lifeless | igc: http://pastebin.com/m43e0952e | 22:43 |
| lifeless | jelmer: hai | 22:50 |
| lifeless | https://code.edge.launchpad.net/~lifeless/subunit/time-support/+merge/9136 :) | 22:50 |
| SamB | oh, does bzr send work with 2a in 1.17+4556+119 ? | 22:52 |
| mwhudson | bzr send (well, bundling) is a bit broken with 2a | 22:52 |
| SamB | I'd heard it was | 22:53 |
| SamB | I thought maybe you'd gotten it fixed | 22:53 |
| SamB | ;-) | 22:53 |
| mwhudson | ah | 22:53 |
| mwhudson | i don't think so, but i've not been paying super close attention | 22:53 |
| * SamB hopes there are at least some failing tests for it | 22:53 | |
| jam | mwhudson: "bit broken" aka completely unusable? | 23:01 |
| jam | I guess you can use "bzr send --no-bundle" :) | 23:02 |
| poolie | hi jam | 23:02 |
| jam | hi poolie | 23:02 |
| jam | SamB: I'm working on it right now, in fact | 23:02 |
| jam | I'm down to 2 test failures | 23:02 |
| mwhudson | jam: right | 23:02 |
| jam | poolie: up for a phone call? | 23:03 |
| * SamB supposes he'll just have to push to launchpad ... | 23:03 | |
| poolie | yes, up specifically for a phone call :) | 23:03 |
| jam | poolie: skype/call my house/call my cell, up to you | 23:03 |
| SamB | hey, if I push a 2a format branch and launchpad wants to stack it on bzr.dev ... what will happen? | 23:03 |
| poolie | ok | 23:04 |
| jam | SamB: it will break | 23:04 |
| jam | but patches/bundles/etc from a 2a branch won't be compatible with bzr.dev (right now) anyway | 23:04 |
| jam | since it will be generated in a rich-root repo, which can't be stored in a non-rich-root | 23:04 |
| jam | note that LarstiQ was looking into what it would take to get all of us upgraded to 2a for bzr branches | 23:05 |
| jam | but he is sleeping now :0 | 23:05 |
| SamB | jam: well, what it took me was jelmer's branch on debian.org having rich-roots ... | 23:06 |
| SamB | where is "rich root" explained? | 23:11 |
| SamB | while we're on that subject, where are "ghosts" explained? | 23:11 |
| lifeless | bzr help repoformats, or some such | 23:11 |
| lifeless | ghosts are explained on the wiki | 23:11 |
| SamB | lifeless: it doesn't actually say what it IS | 23:13 |
| SamB | it just says that changes from rich-root aren't compatible with non-rich-root | 23:13 |
| lifeless | ah | 23:14 |
| maxb | How is it possible for "bzr ls --ignored --versioned --unknown ." to output nothing, in a directory full of files? | 23:16 |
| SamB | if someone symlinked /usr/bin/python to /bin/true ? | 23:17 |
| maxb | hah | 23:19 |
| maxb | no | 23:19 |
| SamB | what's that? you wanted a serious answer? | 23:19 |
| lifeless | maxb: works for me | 23:20 |
| maxb | hrm | 23:21 |
| DaffyDuck_ | lifeless: I have a question. First, can you take a look at http://pastebin.com/d673e2777? | 23:25 |
| DaffyDuck_ | I'm wondering if there's anything bzr can do to make the permissions stick in branches as well. | 23:25 |
| SamB | someone should set up a 2a mirror of the bzr repo soon ... | 23:25 |
| DaffyDuck_ | Someone suggested I use posix acls, but they aren't available for my platform (yet). | 23:26 |
| lifeless | SamB: 2a is rich roots; we want to transition, but we can't accept merges from 2a until we transition | 23:26 |
| SamB | but what ARE they? | 23:27 |
| lifeless | SamB: I think it was covered on the list this morning | 23:27 |
| SamB | ah. thanks ;-) | 23:27 |
| lifeless | DaffyDuck_: your umask is filtering out the write bit | 23:27 |
| DaffyDuck_ | lifeless: Yeah -- I know, but "bzr init" does something which properly inherits the permissions. I was wondering if the same procedure can be applied to branching. | 23:29 |
| lifeless | DaffyDuck_: I'm not sure; you could file a bug with your demonstration of this | 23:30 |
| DaffyDuck_ | lifeless: Ok, I'll do that. Not a biggie, but currently I need to run a "fix_bzr_repo_perm.sh" script each time someone has created a branch in the shared repository. After that, everything works like a charm. | 23:31 |
| jelmer | lifeless: I was about to "vote approve", but lp is down for maintainance | 23:35 |
| lifeless | jelmer: sweet, thanks | 23:36 |
| lifeless | I'll land it all | 23:36 |
| jelmer | lifeless: awesome | 23:37 |
| jelmer | lifeless: I've had positive comments from other Samba devs about subunit | 23:37 |
| jelmer | lifeless: proper reintroduction of duration reports was one of the oft-reported bugs | 23:38 |
| lifeless | please encourage them to file bugs upstream | 23:38 |
| lifeless | feedback is a major source of inspiration | 23:39 |
| jelmer | lifeless: the code that handles subunit in samba is independent of upstream though | 23:40 |
| lifeless | jelmer: yes, but unless there is something upstream about it, I can't know what they are thinking | 23:40 |
| jelmer | lifeless: I'll see if I can forward bugs upstream wrt the specification though if any are reported to me | 23:40 |
| lifeless | and I am very keen to get all your code upstream *anyway* | 23:40 |
| jelmer | lifeless: that's got the stuff wrt "start-testsuite: ".. | 23:41 |
| lifeless | I recall that discussion :) | 23:42 |
| jelmer | lifeless: and the other bit (the buildfarm) is parsing subunit based on regular expressions that match the behaviour of our testsuite | 23:42 |
| jelmer | rather than properly parsing subunit | 23:42 |
| jelmer | the latter will change at some point, when we get the other projects on the buildfarm across to subunit | 23:42 |
| lifeless | I think it will be great when you are able to be building on the subunit commandline tools/tools in trunk | 23:42 |
| lifeless | I'm doing a talk at the end of the month about subunit at the local LUG | 23:43 |
| jelmer | lifeless: yeah, being able to hook into the system subunit would be nice | 23:43 |
| jelmer | it's on my todo list :-) | 23:44 |
| lifeless | jelmer: I missed the shouldStop attribute, I'll add that as a property - ok? | 23:52 |
| jam | poolie: still there? | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!