| === mw is now known as mw|out | ||
| mwhudson | poolie, lifeless, et al: how close is the branch that introduces branch7 to landing? | 00:13 |
|---|---|---|
| spiv | lifeless: http://bazaar-vcs.org/SmartPushAnalysis1.4 | 00:14 |
| pygi | bkor, more answers :D | 00:27 |
| name | hi | 00:35 |
| Odd_Bloke | name: Hey. | 00:38 |
| name | hm does bzr auto merge whitespaces? like foo(bar, x) == foo(bar,x) | 00:39 |
| Odd_Bloke | name: No, those two statements would not be equivalent. | 00:40 |
| spiv | No, it won't. | 00:40 |
| name | damn. to i can't fix whitespaces without risking conflicts | 00:40 |
| LeoNerd | bzr makes no assumptions about the content of the files it protects | 00:41 |
| LeoNerd | Some types of file that may be a big significant change. | 00:41 |
| === BasicPRO is now known as BasicOSX | ||
| lifeless | jam: do mysql use --fixes ? | 00:45 |
| lifeless | name: you could write a merge plugin to handle that | 00:45 |
| name | lifeless: is it easy? | 00:46 |
| lifeless | name: I'm not entirely sure :) | 00:47 |
| lifeless | name: shouldn't be too hard if you are familiar with python though | 00:47 |
| name | i am | 00:48 |
| name | i am | 00:48 |
| name | sorry | 00:48 |
| name | any guide you would suggest? | 00:48 |
| jelmer | that reminds me | 00:50 |
| name | of? | 00:50 |
| jelmer | Odd_Bloke, what's the state of per-file merge algorithms? | 00:50 |
| Odd_Bloke | jelmer: Currently all in my head. | 00:51 |
| jelmer | Odd_Bloke, Heh, ok | 00:52 |
| name | so any tutorial on writing merge plugins? | 00:52 |
| lifeless | jelmer: jam wrote a branch | 01:00 |
| lifeless | name: I can point you at an example | 01:01 |
| lifeless | name: http://bzr.arbash-meinel.com/plugins/per_file_remerge might be useful to examine | 01:01 |
| lifeless | name: but I'm not aware of a tutorial as such | 01:01 |
| name | The requested URL /plugins/per_file_remerge was not found on this server. | 01:04 |
| lifeless | oh | 01:08 |
| lifeless | jam: ^ | 01:08 |
| igc | morning | 01:37 |
| Odd_Bloke | igc: Morning. | 01:39 |
| igc | hi Odd_Bloke | 01:39 |
| lifeless | hi igc | 01:41 |
| Odd_Bloke | igc: What's the preferred way to refer to members the set { working tree, branch, repository } documentation-wise? Is there one? | 01:42 |
| igc | hi lifeless. Want any benchmarking done on OOo today? | 01:42 |
| igc | Odd_Bloke: control directory? | 01:42 |
| lifeless | igc: please | 01:43 |
| lifeless | igc: I'd love usertest run with --btree-plain | 01:43 |
| lifeless | igc: also, is there a dc machine with usertest that I can tweak myself? | 01:43 |
| lifeless | Odd_Bloke: do you mean 'tree, branch,repository are all X' or 'tree is X, branch is Y, repository is Z'? | 01:44 |
| Odd_Bloke | Yeah, that was a terrible explanation on my part, let me give context. | 01:45 |
| Odd_Bloke | I'm trying to say "If none of { branch, tree, repository } were specified" (for check's help) but that seems a bit clunky. Is there an accepted word in the docs to refer to those? I went for elements first, then lifeless suggested objects. | 01:46 |
| Odd_Bloke | But I'd like to stay consistent with the rest of the docs (if there's anything to be consistent with). | 01:46 |
| lifeless | Odd_Bloke: why do you feel the need to specify that much detail? | 01:47 |
| lifeless | Odd_Bloke: specifically: | 01:47 |
| lifeless | Odd_Bloke: tree is an object in a control dir | 01:47 |
| lifeless | ditto branch and repository | 01:47 |
| lifeless | but I think you mean 'If the url given does not have any of <list>' | 01:48 |
| lifeless | ? | 01:48 |
| lifeless | and the general thing that hosts these objects is a control directory. So - 'if no control directory was found' ... | 01:48 |
| Odd_Bloke | Nope, I mean if the user hasn't specified which of <list> to check, bzr will check all plural(<list>) that it finds. | 01:49 |
| Odd_Bloke | And it's not necessarily limited to a single control directory, as if a shared repository location is given, we now check that all of the contained branches are also consistent. | 01:49 |
| lifeless | Odd_Bloke: 'By default check will check all the bzr data found at the supplied URL. If any limits such as --repository are given, then only the named thing is checked.' | 01:50 |
| igc | poolie: what dc machine is running usertest again? | 01:51 |
| poolie | igc, i think that is orgadas | 02:03 |
| poolie | orcadas | 02:03 |
| lifeless | jml: bzr branch lp:mysql | 02:28 |
| lifeless | jml: please try this, and suggest where I should file the bug | 02:28 |
| jml | lifeless: file it on launchpad-bazaar. | 02:30 |
| jml | lifeless: and set it to High, Confirmed. | 02:31 |
| lifeless | jml: bombs away | 02:36 |
| jml | lifeless: I'll get mwh to have a look at it when he gets back. | 02:37 |
| jelmer | woot, svn 1.5 will now recognize and show bzr merges \o/ | 02:37 |
| jelmer | now if bzr only had merge tracking support... | 02:37 |
| jelmer | *cherry* | 02:37 |
| poolie | wow nice | 02:38 |
| lifeless | jelmer: congrats | 02:38 |
| lifeless | jelmer: when do you finish uni ? | 02:38 |
| lifeless | :) | 02:38 |
| jelmer | lifeless: end of the year hopefully | 02:44 |
| poolie | but for now you're on vacation already right? | 02:46 |
| jelmer | yeah, yesterday was my last exam for the semester | 02:48 |
| spiv | jelmer: sweet | 02:48 |
| mark1 | poolie: you free now? that number better than skype? | 03:00 |
| === mark1 is now known as markh | ||
| poolie | markh: either is fine | 03:18 |
| poolie | skype is a bit cheaper if that suits you | 03:19 |
| * igc lunch | 03:30 | |
| poolie | igc, i got your annoyance mail, will print it now :) | 04:04 |
| poolie | and even read it :) | 04:04 |
| igc | thanks poolie :-) | 04:07 |
| jam | lifeless: lp:~jameinel/+junk/per-file-remerge, that is just the stock "public location" for everything that you saw in the commit messages | 04:08 |
| jam | lifeless: afaik mysql does not use --fixes | 04:08 |
| igc | poolie: I also need confirmation that I can merge content filtering as an experimental feature after tweaking | 04:09 |
| lifeless | jam: there is a blog post about how launchpad's bug references are wrong | 04:09 |
| lifeless | jam: if they did use --fixes, we could be right :) | 04:09 |
| poolie | igc, are you confident it won't hurt anything if it's not activeL | 04:11 |
| poolie | ? | 04:11 |
| igc | poolie: let me check that and get back to you | 04:12 |
| Odd_Bloke | jam: Just resent that email. | 04:14 |
| lifeless | man | 04:20 |
| lifeless | writing correct code takes thought | 04:20 |
| mneptok | writing *correctable* code takes an eye on job security. | 04:22 |
| lifeless | thanks mneptok | 04:23 |
| mneptok | anything for you, dear. | 04:25 |
| poolie | that's why they call it support :) | 04:26 |
| lifeless | I don't want mneptok supporting me :) | 04:27 |
| lifeless | thats what I have underpants for! | 04:28 |
| mneptok | i wish *i* had underpants ... | 04:30 |
| poolie | ok, my annotate measurements were incorrect | 04:43 |
| poolie | i didn't have extensions built in one of the branches | 04:43 |
| mwhudson | :) | 04:43 |
| mwhudson | that's a factor of 10-15 right there | 04:43 |
| jml | how can I view the log message for the last revision of a file? | 04:44 |
| lifeless | jml: hmm, bzr log FILE | less | 04:44 |
| jml | lifeless: :( | 04:44 |
| mwhudson | otherwise, programming i guess | 04:45 |
| jml | programming is hard. | 04:45 |
| jml | if programming were easy I wouldn't care about the last log message in the first place :) | 04:45 |
| mwhudson | this programming isn't hard | 04:46 |
| jml | yeah. | 04:46 |
| * jml makes a note to write the relevant patch / plugin | 04:46 | |
| mwhudson | b.repository.get_revision(b.repository.get_inventory(b.last_revision())[mumble].revision) or something | 04:47 |
| lifeless | what | 04:50 |
| lifeless | tree = b.repository.revision_tree(b.last_revision()) | 04:51 |
| poolie | jml, maybe we should make an lp faq for things like this | 04:51 |
| poolie | or something in the developer docs | 04:51 |
| lifeless | wt.paths_to_fileids(PATH, other_trees=[tree]) (something like that, its a UI call) | 04:51 |
| jml | poolie: hmm. | 04:52 |
| jml | poolie: A FAQ's probably a good idea | 04:52 |
| jml | poolie: particularly if the understanding is that some of the items actually represent missing features :) | 04:53 |
| lifeless | mwhudson: generally, revision_tree is better than get_inventory | 04:54 |
| mwhudson | lifeless: oh right, yes | 04:54 |
| lifeless | mwhudson: as revision_tree is richer, but ~= to create | 04:54 |
| mwhudson | lifeless: someone should teach loggerhead this at some point :) | 04:55 |
| poolie | jml, actually maybe a rst document would be good | 04:56 |
| poolie | because it could turn into a doctest and then be accurate | 04:56 |
| jml | poolie: I like text files. | 04:58 |
| poolie | lifeless: i'm trying to come with a name for that method i said could be separated from annotate | 05:09 |
| lifeless | poolie: ok | 05:10 |
| poolie | knit.get_parent_map_for_present_ancestors ? | 05:11 |
| lifeless | what does it do? | 05:12 |
| poolie | http://pastebin.ubuntu.com/24904/ | 05:14 |
| poolie | is that method name a fair description of what it does? | 05:15 |
| lifeless | sure | 05:16 |
| lifeless | note that it gets both local and remote ancestors | 05:16 |
| lifeless | also note that if I wrote that I should have used iter_ancestry, and then captured the parents as I went rather than two API calls | 05:16 |
| igc | spiv: were you planning to merge your InterRemoteToOther patch today? pqm is free fwiw :-) | 05:17 |
| lifeless | jelmer: ping | 05:19 |
| lifeless | some error handling needed: | 05:19 |
| lifeless | bzrlib.plugins.svn.tests.test_branch.WorkingSubversionBranch.test_fetch_dir_upgrade | 05:19 |
| lifeless | Command terminated | 05:20 |
| lifeless | bzrlib.plugins.svn.tests.test_branch.WorkingSubversionBranch.test_fetch_dir_upgrade | 05:20 |
| lifeless | Command terminated | 05:20 |
| jelmer | lifeless: what version of python are you running? | 05:20 |
| jelmer | try "make gdb-check" | 05:20 |
| lifeless | 2.5ish | 05:20 |
| lifeless | jelmer: where | 05:20 |
| jelmer | in the bzr-svn dir | 05:20 |
| mwhudson | quick poll: | 05:20 |
| mwhudson | what should 'bzr get lp://dev/é' do? | 05:21 |
| lifeless | slap you | 05:21 |
| mwhudson | (i'm assuming "what it does now" isn't really acceptable) | 05:21 |
| mwhudson | lifeless: heh | 05:21 |
| lifeless | jelmer: its in gdb | 05:21 |
| jelmer | lifeless: sorry, try: "make gdb-check TESTS=bzrlib.plugins.svn.tests.test_branch.WorkingSubversionBranch.test_fetch_dir_upgrade" | 05:22 |
| jelmer | then run | 05:22 |
| lifeless | Program received signal SIGABRT, Aborted. | 05:23 |
| lifeless | [Switching to Thread 0x2ae68f153cf0 (LWP 6033)] | 05:23 |
| lifeless | #0 0x00002ae68ee23095 in raise () from /lib/libc.so.6 | 05:24 |
| lifeless | #1 0x00002ae68ee24af0 in abort () from /lib/libc.so.6 | 05:24 |
| lifeless | #2 0x00002ae692539d89 in ?? () from /usr/lib/libsvn_subr-1.so.1 | 05:24 |
| lifeless | #3 0x00002ae69276c629 in apr_palloc () from /usr/lib/libapr-1.so.0 | 05:24 |
| lifeless | #4 0x00002ae6918beddd in ?? () from /usr/lib/libsvn_delta-1.so.1 | 05:24 |
| lifeless | #5 0x00002ae692bb096f in ?? () from /usr/lib/libsvn_fs_fs-1.so.1 | 05:24 |
| lifeless | #6 0x00002ae69149722f in txdelta_call (self=0x18e51b0, args=<value optimized out>, kwargs=<value optimized out>) at editor.c:103 | 05:24 |
| lifeless | if you want more, I'll pastebin | 05:24 |
| jelmer | thanks, that seems similar to the issues berto- was seeing earlier | 05:24 |
| lifeless | let me update then | 05:24 |
| lifeless | jelmer: pulling is slow from your repo | 05:27 |
| lifeless | I wonder if rich root pulls are using the pack optimiser :( | 05:27 |
| jelmer | I suspect not | 05:27 |
| lifeless | they are not | 05:27 |
| jelmer | pushing is veeeery slow | 05:27 |
| lifeless | far out | 05:28 |
| lifeless | its doign install revisions | 05:28 |
| lifeless | ahha! | 05:28 |
| lifeless | (Pdb) source._format | 05:29 |
| lifeless | <bzrlib.repofmt.pack_repo.RepositoryFormatKnitPack4 object at 0x185a390> | 05:29 |
| lifeless | (Pdb) self._format | 05:29 |
| lifeless | <bzrlib.repofmt.pack_repo.RepositoryFormatKnitPack3 object at 0x1650a90> | 05:29 |
| lifeless | which is to say | 05:29 |
| jelmer | what's the difference between those two exactly? | 05:29 |
| lifeless | your repository is subtrees | 05:29 |
| lifeless | and my repo is rich root packs | 05:29 |
| jelmer | ah, it probably predates the rich-root formats | 05:29 |
| mlh_ | hah hah: http://gould.cx/ted/blog/Bazaar_Power_Management | 05:30 |
| lifeless | so | 05:30 |
| lifeless | jelmer: align it up, it should be faster:P | 05:30 |
| lifeless | jelmer: still dies | 05:31 |
| jelmer | :-( | 05:31 |
| lifeless | stack looks the same | 05:31 |
| jelmer | lifeless: What exact platform/python/subversion versions? | 05:31 |
| jelmer | (Since I can't reproduce it here) | 05:32 |
| lifeless | amd64 | 05:32 |
| lifeless | 1.4.6dfsg1-2ubuntu1 svn | 05:32 |
| lifeless | 2.5.2-2ubuntu4 | 05:32 |
| lifeless | python | 05:32 |
| jelmer | thanks | 05:32 |
| Verterok | Hi | 05:38 |
| lifeless | hi Verterok | 05:39 |
| Verterok | lifeless: hi :) | 05:39 |
| Verterok | I'm playing a bit with the integration of bzr-search ;) | 05:39 |
| lifeless | cool | 05:39 |
| Verterok | and I have quick question: how can I get a revno from a revid | 05:40 |
| Verterok | ? | 05:40 |
| lifeless | have a look at revspec | 05:40 |
| Verterok | ok, thanks | 05:40 |
| lifeless | also there is some stuff on Branch | 05:40 |
| Verterok | lifeless: FileTextHit are hits in the working tree or also includes text hits in the history? | 05:41 |
| lifeless | only history | 05:41 |
| Verterok | oh, I see... it would be great if I can integrate that just like the text search provided by eclipse | 05:43 |
| Verterok | is there a way I can get the line, length and/or offset of the text hit? | 05:43 |
| lifeless | not at the moment | 05:44 |
| lifeless | its why the summaries are a little kludgy | 05:44 |
| lifeless | mlh_: lol | 05:45 |
| Verterok | lifeless: ok, thanks. to put you in context, I'm working to allow "double click" on FileTextHit and open a read-only editor, (and trying to figure out how to present the mixed results (path/file/revision hits) to the user) | 05:51 |
| lifeless | Verterok: nice | 05:51 |
| * Verterok still needs to learn a thing or two about eclipse search API | 05:52 | |
| lifeless | Verterok: I demoed it last friday | 05:55 |
| lifeless | Verterok: had trouble with eclipse and workspace locking and stuff | 05:55 |
| lifeless | :( | 05:55 |
| Verterok | oh, that's bad :( | 05:55 |
| lifeless | the search bit worked | 05:55 |
| Verterok | cool | 05:56 |
| lifeless | ok, real world data | 05:57 |
| lifeless | which which is the new index: | 05:57 |
| lifeless | real 0m13.602s | 05:57 |
| lifeless | user 0m13.053s | 05:57 |
| lifeless | sys 0m0.200s | 05:57 |
| lifeless | or | 05:57 |
| lifeless | real 0m17.347s | 05:57 |
| lifeless | user 0m15.173s | 05:57 |
| lifeless | sys 0m0.352s | 05:57 |
| spiv | igc: Hmm, I thought I merged that yesterday... I wonder where the success/failure from pqm went? | 06:05 |
| mwhudson | oh hey, pqm does that you you guys too? | 06:05 |
| igc | spiv: it's not there as best as I see. | 06:06 |
| igc | (using log --short on bzr.dev) | 06:06 |
| lifeless | at the moment its teh autopack bug doing that | 06:06 |
| * spiv resubmits | 06:09 | |
| spiv | igc: thanks for noticing :) | 06:09 |
| igc | spiv: the credit belongs to BB, not me! http://bundlebuggy.aaronbentley.com/?selected=mine | 06:17 |
| lifeless | igc: so, ooo ? | 06:19 |
| AfC | Aren't trees like Mozilla and OpenOffice long and linear? That they're big is great, but that they lack much if any branch concurrency would seem to make them less than ideal for your performance tests, no? | 06:23 |
| AfC | [I realize the search for the ideal test case has long been a topic] | 06:23 |
| igc | lifeless: I'm working on it. My first run fell over earlier today so I'm fixing the problem (on my end) and trying again | 06:24 |
| igc | AfC: you're right. | 06:24 |
| igc | there are multiple dimensions ... | 06:25 |
| igc | lots of files | 06:25 |
| igc | deep history | 06:25 |
| igc | complex history | 06:25 |
| igc | my OOo and moz trees cover the first 2 well | 06:25 |
| AfC | igc: sure | 06:25 |
| AfC | The only public projects I'm aware of with all three would be the Linux kernel and MySQL | 06:26 |
| igc | I'm grabbing a copy of mysql now fwiw | 06:26 |
| AfC | Nice | 06:26 |
| rockstar | I've got a dirstate-with-subtree format repo (from bzr-svn) that is Thor knows how old. What's the safest way to upgrade it? | 06:31 |
| lifeless | rockstar: bzr upgrade --pack-0.92-subtree | 06:49 |
| lifeless | wheee | 06:49 |
| rockstar | lifeless, what if I want to lose the subtree support? | 06:49 |
| lifeless | 28609 robertc 18 0 2111m 1.8g 1468 D 0.3 89.6 7:34.69 python | 06:49 |
| Peng | You might be able to upgrade to rich-root-pack, right? | 06:49 |
| lifeless | rockstar: 'bzr pull svn://' | 06:49 |
| * Peng goes to bed. | 06:49 | |
| lifeless | rockstar: (you can't downgrade model data, subtrees store more data than rich roots) | 06:53 |
| lifeless | poolie: you back ? | 06:57 |
| lifeless | spiv: know of a python module to parse proc/pid/statm ? | 07:04 |
| lifeless | crap! holy! | 07:05 |
| lifeless | robertc@lifeless-64:~/source/python/python-btree$ du -sh .bzr/repository/indices/ | 07:05 |
| lifeless | 4.6M .bzr/repository/indices/ | 07:05 |
| lifeless | robertc@lifeless-64:~/source/python/python-btree$ du -sh ../python-packs/.bzr/repository/indices/ | 07:05 |
| lifeless | 38M ../python-packs/.bzr/repository/indices/ | 07:06 |
| poolie | lifeless: back now | 07:11 |
| poolie | igc: wow that's really good! | 07:12 |
| igc | poolie: thanks | 07:12 |
| spiv | lifeless: I don't, unfortunately | 07:12 |
| spiv | lifeless: although I think jam maybe had code to read it? | 07:13 |
| poolie | i have some more feedback, will send mail | 07:13 |
| igc | looking forward to it | 07:13 |
| lifeless | spiv: read it is easy :). | 07:15 |
| lifeless | spiv: I just need to figure which like is vss | 07:15 |
| spiv | lifeless: actually... | 07:16 |
| spiv | lifeless: http://www.pixelbeat.org/scripts/ps_mem.py | 07:17 |
| spiv | lifeless: that code isn't really structured for importability, but it might be a useful reference | 07:18 |
| lifeless | so, python via svn | 07:18 |
| lifeless | 149M packs + 38M indices -> 149M packs + 4.6M indices | 07:18 |
| lifeless | 187 -> 154 | 07:18 |
| spiv | That's a much nicer data:index ratio. | 07:19 |
| lifeless | 33/187 shrink in repo size | 07:19 |
| lifeless | 17% | 07:19 |
| igc | lifeless: awesome | 07:20 |
| lifeless | log time was indisinguishable | 07:20 |
| lifeless | but they are fully packed so meh | 07:20 |
| lifeless | howeveer, I'm now going to try to get a peak VSS reading | 07:21 |
| AfC | lifeless: maybe you should write a scriptlet that breaks a repository into chunks each of a random number of revisions | 07:25 |
| spiv | You could call it "bzr unpack" ;) | 07:26 |
| AfC | spiv: probably better than `bzr randomize`. If (incorrect) word got out that there was a command that would arbitrarily scramble data in a repository we'd never hear the end of it. :) | 07:27 |
| lifeless | spiv: I could | 07:28 |
| lifeless | spiv: or | 07:28 |
| lifeless | spiv: I could just use my 22G presplit test repo :) | 07:28 |
| lifeless | spiv: ahh! | 07:29 |
| lifeless | spiv: /proc/pid/status | 07:29 |
| lifeless | spiv: http://rafb.net/p/EbcdpJ48.html | 07:43 |
| lifeless | spiv: give that a spin. | 07:43 |
| lifeless | VmPeak: 296680 kB | 07:44 |
| spiv | That looks like a handy patch. | 07:45 |
| lifeless | and | 07:45 |
| lifeless | VmPeak: 300408 kB | 07:46 |
| lifeless | so | 07:46 |
| lifeless | I'm amazed how much memory log uses up | 07:46 |
| spiv | I'm not sure that VmPeak is the most useful number. I think it might report values much higher than the highest resident memory size, because it's the peak of the virtual size? | 07:49 |
| lifeless | this is true | 07:49 |
| lifeless | so the question is when is high VM and low resident good | 07:50 |
| lifeless | answer - never :) | 07:50 |
| spiv | I wonder if VmHWM is any better? Pity my man proc(5) doesn't describe these fields. | 07:50 |
| lifeless | so | 07:50 |
| lifeless | I put a pause in there | 07:50 |
| lifeless | I see this: | 07:50 |
| lifeless | 15212 robertc 20 0 299m 88m 5856 S 0 4.4 0:27.62 python | 07:50 |
| lifeless | VmPeak: 300576 kB | 07:50 |
| lifeless | VmSize: 298116 kB | 07:50 |
| lifeless | VmHWM: 93068 kB | 07:51 |
| lifeless | VmRSS: 90508 kB | 07:51 |
| weigon | lifeless: if you can use valgrind there is the massif plugin | 07:51 |
| weigon | lifeless: it tracks heap-allocations over time | 07:51 |
| lifeless | weigon: we can | 07:51 |
| lifeless | weigon: I wanted something incredibly lightweight though | 07:51 |
| weigon | http://developer.gnome.org/doc/guides/optimisation/Massif.html ... k | 07:52 |
| lifeless | weigon: just a 'does BTreeIndex peak higher' | 07:52 |
| AfC | You know, with all the smart people hacking on Linux, you'd think that procps would have found a way to output useful numbers by now. | 07:52 |
| spiv | lifeless: that seems to tally (90508/1024 ~= 88.3) | 07:52 |
| lifeless | spiv: yes :) | 07:52 |
| spiv | AfC: http://lwn.net/Articles/230975/ sound promising | 07:53 |
| lifeless | spiv: so I think the VmHWM is probably the immediately interesting thing | 07:53 |
| spiv | Agreed. | 07:53 |
| lifeless | spiv: however, keeping VmPeak low is good too | 07:53 |
| * spiv nods. | 07:53 | |
| lifeless | here's another one I prepared earlier | 07:53 |
| lifeless | 28609 robertc 18 0 2182m 1.9g 1432 D 0.7 97.3 8:18.83 python | 07:54 |
| lifeless | spiv: r=spiv on that patch btw ? | 07:54 |
| lifeless | should I NEWS it? add a guard for windows (but will it work on bsd ?) | 07:54 |
| spiv | lifeless: Just add a guard on the file existing, I think. | 07:54 |
| spiv | lifeless: I'm happy to have that merged, I think. | 07:55 |
| lifeless | try: | 07:55 |
| lifeless | status_file = file('/proc/%s/status' % os.getpid(), 'rb') | 07:55 |
| lifeless | except: | 07:55 |
| lifeless | pass | 07:55 |
| lifeless | else: | 07:55 |
| lifeless | sufficiently ugly ? | 07:55 |
| spiv | Yeah :) | 07:55 |
| spiv | Well, | 07:55 |
| spiv | Not a bare except. | 07:55 |
| lifeless | bare except | 07:55 |
| spiv | No, just IOError | 07:56 |
| spiv | That should cover all reasonable exceptions, rather than e.g. KeyboardInterrupt. | 07:56 |
| spiv | Python's docs are pretty clear that "If the file cannot be opened, IOError is raised. " | 07:56 |
| lifeless | committing | 07:56 |
| lifeless | so anyhow | 08:01 |
| lifeless | that 4G process | 08:01 |
| lifeless | Virt + res is pretty high :) | 08:01 |
| lifeless | weigon: the other problem is we need python backtraces on allocation pressure; and python allocates arenas no objects | 08:06 |
| weigon | lifeless: you can't disable for debugging ? | 08:06 |
| weigon | but yeah, that doesn't help with the python stacktraces | 08:07 |
| lifeless | I really like to have a toolchain that can debug in production | 08:07 |
| lifeless | it makes it a lot easier to fix something a user reports | 08:07 |
| spiv | You can rebuild python to use plain malloc rather than its "pymalloc", but then you have to rebuild all extension modules you use too. | 08:08 |
| igc | lifeless: those test results are still some time off. I'll email them to you overnight. Off to the hospital for a short visit now and dinner after that so I'll be offline for a while | 08:08 |
| lifeless | igc: ok, see you online in weird timezones :) | 08:08 |
| weigon | glib2 also uses "slices" but you can disable that at runtime with G_SLICE="always-malloc" | 08:09 |
| spiv | (I wonder if it's possible to override that with an LD_PRELOAD hack?) | 08:09 |
| === brilliantout is now known as brilliantnut | ||
| === brilliantnut is now known as brilliantout | ||
| jelmer | ToyKeeper, ping | 09:19 |
| ToyKeeper | 'lo | 09:25 |
| ToyKeeper | jelmer: yes? | 09:25 |
| jelmer | ToyKeeper, Do you still have that sawfish branch around? | 09:25 |
| ToyKeeper | Yeah. | 09:25 |
| ToyKeeper | I was actually just looking again at how best to convert svn to bzr without losing tags... | 09:26 |
| jelmer | ToyKeeper: If you try to push that to a remote location using the bzr smart server protocol, does it also use this much memory? | 09:26 |
| ToyKeeper | I'll check... | 09:26 |
| jelmer | ToyKeeper: Try the latest bzr-svn revisions, it sets real bzr tags now | 09:27 |
| jelmer | (although it doesn't pull in the revisions they point at yet) | 09:27 |
| ToyKeeper | Well, it's running. I'll let you know. :) | 09:32 |
| ToyKeeper | It works with a fresh dir, though when I tried a new branch in a fresh repo, it wasn't too happy. "ERROR: Repository KnitPackRepository('srcURL') is not compatible with repository KnitPackRepository('destURL')" | 09:33 |
| jelmer | you need a rich root repo | 09:33 |
| ToyKeeper | jelmer: BTW, are you wondering about memory use on the sender or the receiver? | 09:33 |
| jelmer | ToyKeeper, both, actually (I'm wondering if the high memory use is in bzr itself as well) | 09:34 |
| jelmer | spiv, ping | 09:35 |
| ToyKeeper | jelmer: Okay. 3 minutes. 88 MB on the client, 24MB on the server. | 09:41 |
| jelmer | ToyKeeper, Hmm, so at least that's not the problem. Thanks. | 09:41 |
| ToyKeeper | (client was the same bzr.dev which spiked in the bug report... server was bzr 1.5) | 09:42 |
| ToyKeeper | I doubt it matters, but 'bzr serve' was proxied through bzr_access. | 09:42 |
| Laibsch | I am trying to check an svn repo into bzr | 10:08 |
| Laibsch | I am seeing some strange issues | 10:08 |
| Laibsch | http://rafb.net/p/Y0s6oC57.html | 10:08 |
| Laibsch | svn itself works fine, though | 10:08 |
| Laibsch | any idea? | 10:09 |
| LarstiQ | Laibsch: does something like mtr actually reach that host? It seems more like general networking problems. | 10:10 |
| Laibsch | ping does | 10:10 |
| Laibsch | and svn itself can check out fine | 10:10 |
| Laibsch | iptables -L lists nothing | 10:10 |
| LarstiQ | Laibsch: and it wasn't a transient error? | 10:10 |
| Laibsch | no | 10:10 |
| LarstiQ | Laibsch: the fact that telnet experiences the same problem.. | 10:12 |
| LarstiQ | Laibsch: in fact, I get the same error. | 10:13 |
| Laibsch | Well, maybe the telnet command is not correct | 10:14 |
| Laibsch | Can you try the bzr get command? | 10:14 |
| LarstiQ | same problem | 10:15 |
| LarstiQ | Laibsch: I'll look further into it after I handle some other stuff. | 10:15 |
| ToyKeeper | Laibsch: That host appears to return 'no route' for blocked ports instead of the usual reject (or just no response at all). | 10:16 |
| LarstiQ | Laibsch: you're sure that's the correct url though? | 10:16 |
| ToyKeeper | I can talk to it via ping and ssh, but not svn. | 10:17 |
| ToyKeeper | nmap might reveal some other ports, but it takes a little while. | 10:17 |
| luks | Laibsch: 'svn co' doesn't work for me on that URL | 10:18 |
| luks | fails with the same error | 10:18 |
| luks | looks like a server issue to me | 10:19 |
| Laibsch | svn checkout http://cvs.gnucash.org/repo//gnucash/branches/aqbanking3 | 10:19 |
| Laibsch | works | 10:19 |
| ToyKeeper | http != svn :) | 10:19 |
| Laibsch | Maybe I was mistaken in replacing the http with svn | 10:19 |
| LarstiQ | Laibsch: http:// != svn:// | 10:19 |
| LarstiQ | Laibsch: yeah :) | 10:19 |
| Laibsch | OK | 10:19 |
| Laibsch | Sorry for the noise | 10:19 |
| LarstiQ | Laibsch: well, thank you for showing me a host that acts weird like that :) | 10:20 |
| Laibsch | hehe | 10:20 |
| Laibsch | The checkout with bzr still fails | 10:20 |
| Laibsch | $ bzr get http://cvs.gnucash.org/repo//gnucash/branches/aqbanking3 | 10:20 |
| Laibsch | bzr: ERROR: Transport error: Server refuses to fullfil the request | 10:20 |
| Laibsch | s/bzr get/svn checkout/ | 10:21 |
| Laibsch | and it works | 10:21 |
| ToyKeeper | I get the same error for both. | 10:21 |
| luks | `bzr branch svn+http://cvs.gnucash.org/repo/gnucash/branches/aqbanking3` works for me | 10:23 |
| luks | or, well, attempts to work :) | 10:24 |
| Laibsch | As an infrequent bzr (I used monotone extensively) I have to say that bzr used to start fine with a clean interface | 10:24 |
| Laibsch | now it has so many weird and inconsistent switches :-( | 10:24 |
| Laibsch | It would be awesome to streamline that in the future | 10:24 |
| luks | what specifically do you mean? | 10:25 |
| Laibsch | Just one example | 10:25 |
| Laibsch | bzr get | 10:25 |
| Laibsch | bzr pull | 10:25 |
| Laibsch | bzr branch | 10:25 |
| Laibsch | More or less the "same thing" | 10:25 |
| luks | get, branch and clone are aliases for the same thing | 10:25 |
| luks | pull is something completely different | 10:25 |
| ToyKeeper | In any case, it looks like the admin for cvs.gnucash.org is too clever for his own good. | 10:25 |
| Laibsch | could be | 10:25 |
| Laibsch | what is the specific problem? | 10:26 |
| Laibsch | I'll raise the issue | 10:26 |
| ToyKeeper | The ICMP 'host unreachable' response may be a neat trick, but it's not supposed to be used for port blocking. | 10:27 |
| ToyKeeper | Tell the admin to drop unwanted packets instead of returning a host-unreachable error. | 10:27 |
| ToyKeeper | A 'port unreachable' response works too, and should be the default behavior from iptables REJECT (but many prefer DROP, which is fine). | 10:29 |
| Laibsch | so, this is an iptables configuration? | 10:30 |
| ToyKeeper | Probably. | 10:31 |
| ToyKeeper | I didn't even try to guess what OS the server/router is running, but if it's Linux, it would be an iptables config problem. | 10:32 |
| jelmer | Laibsch: The "bzr: ERROR: Transport error: Server refuses to fullfil the request" bit is a bug that'll be fixed in 1.6 | 10:39 |
| ToyKeeper | hrrm. | 11:03 |
| ToyKeeper | I don't suppose there's any way to do per-branch aliases, is there? | 11:04 |
| ToyKeeper | (or per-repository) | 11:05 |
| ToyKeeper | ... looking for a way to name URLs, basically, to be able to "bzr push backup" or "bzr push public" from the same branch. | 11:05 |
| lifeless | ToyKeeper: I believe that landed yesterday in bzr.dev | 11:07 |
| jelmer | lifeless: is there some easy way to store non-versioned revision metadata? | 11:32 |
| jelmer | (trying to fix bug 161830) | 11:33 |
| ubottu | Launchpad bug 161830 in bzr-svn "log should show subversion revision numbers as well as branch/bzr revision info" [Wishlist,Triaged] https://launchpad.net/bugs/161830 | 11:33 |
| lifeless | jelmer: so you need to associate a svn number with a bzr after creating the bzr revision ? | 11:35 |
| jelmer | yeah | 11:35 |
| jelmer | ideally something that always propagates with the branch | 11:35 |
| lifeless | sounds like a tag in principle | 11:35 |
| jelmer | but I realize there isn't something like that | 11:35 |
| jelmer | I'm not sure the tags infrastructure is made for storing 10s of thousands of entries atm :-) | 11:36 |
| jelmer | although in concept, yeah it does sound like a tag | 11:36 |
| lifeless | its not made for that | 11:37 |
| lifeless | as usual I have some ideas here | 11:38 |
| jelmer | commit log alteration would need a similar store I think | 11:38 |
| jelmer | lifeless: What are your ideas? | 11:40 |
| lifeless | commit log alteration is entirely different | 11:40 |
| lifeless | because thats distributed database integrity you're facing | 11:41 |
| jelmer | lifeless, Depends on how you implement it | 11:41 |
| lifeless | jelmer: well its 'versioned' vs 'nonversioned' | 11:41 |
| jelmer | lifeless: I wasn't thinking of actually modifying the revision object, rather keeping extra metadata per revision of modifications | 11:42 |
| jelmer | lifeless, Anyway, getting sidetracked.. what about the revision number metadata? | 11:43 |
| lifeless | jelmer: so, to scale to huge tag counts | 11:43 |
| lifeless | I'm thinking of an updatable pack like store | 11:43 |
| lifeless | the key point being that a key in the store can be replaced (unlike pack stores) | 11:46 |
| lifeless | and deletes are done by replacing with a special marker | 11:46 |
| lifeless | however | 11:47 |
| lifeless | a difference for svn revno is that they are repo global, unlike tags | 11:47 |
| lifeless | so this would live in the repo | 11:47 |
| lifeless | and fetch would need some efficient query to get new journal items from such a store for already fetched revisions | 11:47 |
| hypest | hello. Does anyone know how to setup bzr (1.5) diff to pass the actual current file (not a copy of it) to the external diff program? | 11:48 |
| lifeless | we'd want this to be generic and usable for other things too | 11:48 |
| jelmer | lifeless: makes sense | 11:49 |
| jelmer | hypest: Hi | 11:50 |
| jelmer | lifeless: Separate files per function though? | 11:50 |
| jelmer | lifeless: The problem with keeping things in .bzr/ is that they're not kept when cloning | 11:50 |
| jelmer | with keeping *custom* things | 11:51 |
| lifeless | jelmer: one store. hints on things in it for locality of reference as needed. | 11:51 |
| lifeless | jelmer: hooked into the system so that fetch knows what to copy even if a plugin is missing - but conflicts require the plugin to resolve | 11:52 |
| jelmer | lifeless: that sounds ideal | 11:54 |
| jelmer | lifeless: I have considered keeping part of the bzr-svn cache in .bzr/ but this is what stopped me | 11:54 |
| jelmer | lifeless: It could make e.g. "bzr branch http://bzr-mirror.gnome.org/svn/gnome-specimen/trunk; bzr push -d trunk svn://svn.gnome.org/svn/gnome-specimen/trunk" very quick | 11:55 |
| hypest | my goal is to be able to use the external diff program as editor. My scenario: using winmerge, I can inspect the file's changes, (want to) revert some of them, and save the file. Since bzr passes a copy to winmerge, saving is "destroyed"... | 11:56 |
| jelmer | hypest: i remember there was something changed in that regard recently | 11:56 |
| jelmer | hypest: On POSIX systems, a symlink is used rather than a file copy | 11:57 |
| lifeless | hypest: I'm not sure | 11:57 |
| jelmer | lifeless, Is any of this specced on the wiki btw? Or just in your head? | 11:59 |
| lifeless | in my head | 12:00 |
| hypest | jelmer: haven't found it yet... ofcource I'll keep looking. I'm on WinXP by the way, so the symlink way I assume does not apply. | 12:00 |
| jelmer | bug 81689 | 12:01 |
| ubottu | Launchpad bug 81689 in bzr "Branches with symlinks can't be checked out on Windows" [Medium,Confirmed] https://launchpad.net/bugs/81689 | 12:01 |
| jelmer | hmmno, that's different | 12:02 |
| jelmer | No, I can't find it either, maybe it didn't get mentioned in NEWS | 12:03 |
| hypest | so, should I post a bug report, a feature request, or nothing? | 12:07 |
| jelmer | hypest: please file a bug | 12:08 |
| hypest | jelmer: thanx ;) | 12:09 |
| === brilliantout is now known as brilliantnut | ||
| hypest | done: filed the bug report: https://bugs.launchpad.net/bzr/+bug/245481 | 12:27 |
| ubottu | Launchpad bug 245481 in bzr "current file name passed via a copy to external diff, under Windows" [Undecided,New] | 12:27 |
| === james_w_ is now known as james_w | ||
| lifeless | Pieter: what git window and depth do you use for best compression? | 13:42 |
| === emgent_ is now known as emgent | ||
| lifeless | man | 13:45 |
| lifeless | http://63.246.7.136/articles/dvcs-guide is so biased | 13:45 |
| lifeless | 'Bzr pretends to hide complexity by keeping a clean User Interface while ...' | 13:45 |
| Pieter | lifeless: 200 for both is about the max | 13:50 |
| Pieter | lifeless: but if your repository is small (< 100k commits) you can take a smaller window and have a faster repacking | 13:50 |
| lifeless | Jc2k: why does the viewvc link http://bzr-mirror.gnome.org/cheese/trunk/ point to svn ? | 13:54 |
| luks | lifeless: because ViewVC doesn't support bzr? | 13:56 |
| lifeless | luks: there is loggerhead running on the same machine | 13:56 |
| lifeless | luks: http://bzr-mirror.gnome.org:8080/cheese/trunk/changes | 13:56 |
| lifeless | luks: try the search box :P | 13:57 |
| matkor | hmm what they mean by "Directories versionable" ? | 13:58 |
| james_w | beuno: hey, you about? | 13:58 |
| beuno | james_w, hey, yup | 13:58 |
| james_w | hey lifeless | 13:59 |
| james_w | beuno: any news on next week? | 13:59 |
| lifeless | hi james_w | 13:59 |
| beuno | james_w, yeah, I'm here next week for sure :) | 13:59 |
| james_w | beuno: great, I'll see about popping down for a day. | 13:59 |
| lifeless | james_w: you're not at GUADEC? | 13:59 |
| james_w | lifeless: nope, sorry. | 14:00 |
| james_w | are you flying out tomorrow? | 14:00 |
| lifeless | james_w: yes. guadec, then london, then LRL | 14:00 |
| james_w | are you speaking at LRL? | 14:01 |
| lifeless | yes | 14:01 |
| beuno | james_w, cool! I'll be mostly working with mpt, so I'll probably be on a desk somewhere | 14:02 |
| beuno | lifeless, when are you coming to london? | 14:02 |
| lifeless | beuno: after GUADEC | 14:02 |
| lifeless | 13th | 14:03 |
| beuno | lifeless, ah, I will probably leave the 12th :/ | 14:03 |
| === thekorn_ is now known as thekorn | ||
| === mw|out is now known as mw | ||
| * jelmer will also be at LRL again | 14:14 | |
| * beuno wonders what LRL is | 14:16 | |
| lifeless | lug radio live | 14:16 |
| jelmer | LUGRadio Live, http://www.lugradio.org/ | 14:16 |
| beuno | ah, so I'm leaving when everyone is coming... meh | 14:17 |
| lifeless | beuno: you should have chatted to us, could have coordinated: ) | 14:17 |
| beuno | lifeless, yeah, I wasn't expecting to cross half the globe. I got asked on friday and was on a plane tuesday | 14:18 |
| jelmer | is there any sort of sprint planned near LRL? | 14:19 |
| jelmer | I hadn't realized there would be more bzrers there | 14:19 |
| lifeless | jelmer: don't think so | 14:19 |
| lifeless | jelmer: I'm heading home sunday, but perhaps we can just make some time | 14:20 |
| lifeless | abentley: around ? | 14:21 |
| abentley | lifeless: hi | 14:21 |
| lifeless | abentley: do we have a sequence matcher style thing in bzrlib that can report AB -> BA as a move of A or B rather than a delete/add ? | 14:21 |
| lifeless | abentley: I have an idea I'd like to toy with | 14:22 |
| abentley | lifeless: No, we don't have anything like that that I know of. | 14:22 |
| lifeless | K, I guess I'll write it :) | 14:23 |
| abentley | But when I talked with John about it, he suggested doing multiple passes. | 14:23 |
| abentley | With the existing sequence matcher. | 14:23 |
| lifeless | this is for text reconstruction | 14:24 |
| lifeless | I suspect a dict + single pass is all I need | 14:24 |
| lifeless | though range output would be cheaper to represent | 14:24 |
| lifeless | how would multiple passes work ? | 14:25 |
| abentley | Do a sequence match. Then do a sequence match against all lines that didn't match from the previous pass. | 14:26 |
| lifeless | I see | 14:26 |
| lifeless | so the first says A gone, B matched, A' is new, the second says A' matches | 14:26 |
| abentley | Right. | 14:27 |
| lifeless | so what I'm going to trry | 14:27 |
| lifeless | is to write a VF implementation that uses single linear delta chains | 14:27 |
| lifeless | given texts A, B, C it will serialise this as A, A->B, (A+A->B)->C | 14:28 |
| lifeless | which will give the same compression as multiparent I believe | 14:28 |
| lifeless | and the same IO as current knit chains, but in a single contiguous block | 14:29 |
| lifeless | and only one delta to apply on reconstruction | 14:29 |
| lifeless | (reading will require 3 pieces of information: basis start, basis length, basis end | 14:30 |
| lifeless | erm, that last one is delta length | 14:30 |
| lifeless | abentley: what do you think? | 14:31 |
| abentley | I don't understand how you can reconstruct C with a single delta. | 14:31 |
| lifeless | to make the delta for C | 14:32 |
| lifeless | take the lines for A and the lines for the delta A->B, combined | 14:32 |
| lifeless | then delta that combined text against C to make the delta | 14:32 |
| abentley | I see. | 14:32 |
| lifeless | you probably see the implications | 14:33 |
| abentley | I didn't quite grok your notation at first. | 14:33 |
| lifeless | but to spell it out and answer your question :), to get C back, read A and the A->B delta into a lines list, then read and parse the delta to C and apply it | 14:33 |
| abentley | So you're trying to solve the problem of repeated delta application? | 14:34 |
| lifeless | it will delete all the metadata about A and the A->B delta, and reorder some of the lines from the A->B delta etc, and possibly also add lines | 14:34 |
| lifeless | abentley: I'm sick and tired of repository size being raised as an issue | 14:34 |
| lifeless | abentley: and this came to me today | 14:34 |
| lifeless | it seems to balance out most everything we've previously discussed about getting good compression/reconstruction etc | 14:35 |
| lifeless | (clearly you can get A and B etc out concurrently if desired | 14:35 |
| abentley | What's the advantage over multiparent? | 14:37 |
| lifeless | abentley: linear IO with capped depth | 14:37 |
| abentley | you're only going to get linear IO in an optimized pack, and only for some revisions. | 14:38 |
| Jc2k | lifeless: because i don't consider 8080 'live' yet, even though it got blogged about | 14:39 |
| Jc2k | thats not that i don't think its ready | 14:39 |
| abentley | You can also get linear IO in an optimized pack for some revisions with multiparent. | 14:39 |
| Jc2k | just that i havent had time to hide it behind apache proxy redirects and update the templates and stuff | 14:39 |
| lifeless | abentley: so, my theory is that if its fast enough (for instance, unlike gits approach it won't need to test N different texts), we can just redelta on auto pack | 14:40 |
| abentley | And you can certainly cap the number of revisions required to generate a multiparent diff. | 14:40 |
| abentley | sorry "cap the number of deltas required to reconstruct a fulltext from a multiparent diff" | 14:41 |
| lifeless | I know we can cap the number of deltas, but it seems to require either multiple fulltexts, or fulltexts at dominators | 14:41 |
| abentley | I'm not sure I follow. You just count the number of deltas required, and if that exceeds X, you generate a fulltext. | 14:43 |
| lifeless | for linear IO, multiparent seems quite a bit worse at that because only the simplest of graphs will have uninterrupted runs 100's of deltas long without bifurcation | 14:43 |
| lifeless | abentley: say I have a graph A:[], B:[A], C:[A], F[chain back to B], G[chains back to C], H:[F, G] | 14:44 |
| lifeless | abentley: the 'chain back to B' - imagine thats (say) 50 texts in a row | 14:45 |
| lifeless | if H is not a fulltext, and A is further back than our threshold, we have to have two fulltexts read in to reconstruct H | 14:45 |
| lifeless | one on the F leg, and one on the G leg. | 14:46 |
| abentley | lifeless: Are we saying linear vs random, or linear as "uninterrupted"? | 14:46 |
| lifeless | abentley: uninterrupted adjacent | 14:46 |
| abentley | So both, then. | 14:46 |
| lifeless | yes | 14:46 |
| lifeless | I want to remove the build-graph logic entirely from text building | 14:47 |
| lifeless | or at least, to make it the uncommon case | 14:47 |
| abentley | But if A is not further back than our threshold, we can't get linear access to both F and G. | 14:49 |
| lifeless | with MP diffs, no. | 14:49 |
| abentley | In fact, we can't get linear access to both B and C. | 14:49 |
| lifeless | nor with knits | 14:50 |
| abentley | How is it different with yours? | 14:50 |
| abentley | How can your do linear access to reconstruct B and linear access to reconstruct C? | 14:50 |
| lifeless | changing notation to avoid typing as much... the compressor I'm talking about might compress this as A,->B,->C,-D,-E,...->F,->G,->H | 14:51 |
| lifeless | where each ->FOO is 'delta the previous output to FOO' | 14:52 |
| lifeless | we can to a certain extent do this with stock MP by just interlacing the diffs and sucking up any overlap | 14:53 |
| abentley | I thought you were drawing the build graph. | 14:53 |
| lifeless | abentley: I was drawing the text graph, which is what I understand MPDiff to compress against | 14:53 |
| lifeless | abentley: a way to express it in MPDiff terms would be to have A be a NewText, B be a diffagainst A; C be a diff against A,B; D be a diff against A,B,C | 14:55 |
| abentley | lifeless: That's the way current generators do it, but MPDiff doesn't require the build graph to reflect the history. | 14:55 |
| lifeless | abentley: I clicked to that :) | 14:55 |
| jelmer | grrr @ overheating intel hardware :-( | 14:55 |
| jelmer | lifeless: Yeah, I'd be up for some sprinting if there is time | 14:56 |
| lifeless | abentley: the different though is that that would require compression-depth sequence matches to output each additional diff | 14:56 |
| lifeless | abentley: whereas what I'm proposing only requires one match | 14:56 |
| Pieter | where there's a match, there's a flam | 14:57 |
| Pieter | e | 14:57 |
| lifeless | abentley: so its using the knowledge gained during each diff's generation to keep the overhead on generating the next diff capped | 14:57 |
| abentley | That's interesting. | 14:58 |
| lifeless | abentley: anyhow, I'll give it a spin and compare it against bundles, which I figure are about optimal in size (but have no fulltexts), and compare insert/extraction speed | 14:58 |
| lifeless | in theory, if gzip was perfect, this is equivalent to: | 14:59 |
| lifeless | gzip(A+B+C+D+E+F+G+H) | 14:59 |
| lifeless | and I plan to profile that too :) | 14:59 |
| lifeless | man, why doesn't evolution do full text indexing. | 15:00 |
| lifeless | WTB featurs | 15:00 |
| abentley | lifeless: So, to solve your original issue, it might be practical to run a sequence match against the lines from each input diff. | 15:00 |
| lifeless | abentley: right, diff is small | 15:01 |
| lifeless | abentley: so many diffs, but we expect them to be very fast | 15:01 |
| lifeless | good idea | 15:01 |
| abentley | So if we have A, B, C and we're generating D, you match (lines-from-A) against current, then match (lines-from-b) against unmatched-in-current. | 15:01 |
| lifeless | I'll see how badly something naive pans out | 15:02 |
| abentley | Cool. | 15:02 |
| lifeless | if I'm right it will show serious promise on extraction and size and we can tune the compressor to our hearts content once the point is proven | 15:03 |
| abentley | Because all of the previous diffs will have been generated by the same process, you probably won't get redundant matches. | 15:03 |
| lifeless | abentley: can't get - we'd be stripping matches out anyhow | 15:04 |
| sabdfl | where's the best place to get the loom plugin? | 15:05 |
| abentley | One thing I think we lose vs MP is the ability to extract a sequence match vs X directly. | 15:05 |
| abentley | sabdfl: lp:bzr-loom | 15:06 |
| sabdfl | thanks abentley | 15:07 |
| johan | Hi, I've been having some problems setting up pqm, is there a tutorial available somewhere? | 15:07 |
| * johan looks at lifeless | 15:07 | |
| lifeless | abentley: we would definitely lose that. We can look at storing the line indices for that concurrently | 15:07 |
| abentley | sabdfl: np | 15:07 |
| lifeless | Odd_Bloke: johan: meet each other :)( | 15:07 |
| lifeless | its midnight, and I have to halt() or I won't be packed for GUADEC | 15:08 |
| johan | oh | 15:08 |
| lifeless | johan: Odd_Bloke is in UK time and hacking on pqm at the moment | 15:09 |
| lifeless | johan: there is a full docbook manual for pqm FWIW. | 15:09 |
| lifeless | anyhow, I'm off | 15:09 |
| lifeless | sabdfl: see you on the flipside | 15:09 |
| Laibsch | I am back to my problem of importing gnucash svn http://rafb.net/p/ig6EvE25.html | 15:09 |
| Laibsch | What can I do? | 15:09 |
| Laibsch | The admin is now online | 15:10 |
| Laibsch | If there is anything to do from his side, I can talk to him | 15:10 |
| Laibsch | But he thinks the host blocking is what he wants | 15:10 |
| johan | lifeless: thanks, I'll ask him about my troubles (mostly related to merges, configuring branches) | 15:10 |
| lifeless | johan: oh, also Kinnison runs a pqm last I heard :) | 15:11 |
| lifeless | really gone | 15:11 |
| Laibsch | jelmer, ToyKeeper, LarstiQ: Can you help me? | 15:17 |
| Kinnison | Aye, I do run a pqm | 15:17 |
| Kinnison | but it's ages since I set it up | 15:17 |
| Kinnison | johan: what seems to be the problem? | 15:17 |
| LarstiQ | Laibsch: that pastebin looks like a different problem than admin configs | 15:19 |
| Laibsch | LarstiQ: yes | 15:20 |
| Laibsch | The question is, what kind of problem | 15:21 |
| LarstiQ | Laibsch: one I hope to find in bzr-svn bugs, just a secx | 15:22 |
| LarstiQ | sec | 15:22 |
| johan | Kinnison: I get an error message when doing the merge, saying Sender not authorised to commit to branch xxx | 15:22 |
| jelmer | Laibsch: which version of bzr-svn is this? | 15:23 |
| * Laibsch hopes that the bug LarstiQ will find doeshave a fix ready | 15:23 | |
| Laibsch | jelmer: latest hardy | 15:23 |
| Laibsch | 0.4.9 IIRC | 15:23 |
| Kinnison | johan: Have you prepared a gpg keyring with your keys in it? | 15:23 |
| jelmer | Laibsch: if it's 0.4.10, this is an issue that's fixed in the development branch | 15:23 |
| Kinnison | johan: and associated that with the branch? | 15:23 |
| Kinnison | e.g. with keyring=/home/dsilvers/websites/digital-scurf.org/bzr/pqm-home/permitted-keys.pu | 15:24 |
| Kinnison | b | 15:24 |
| Laibsch | jelmer: Actually, I was lying. This was on a remote debian sid box and indeed it was 0.4.10 | 15:24 |
| johan | Kinnison: keyring=/home/pqm/.gnupg/pubring.gpg this is what I have | 15:24 |
| jelmer | I'm I guess I have to release 0.4.11 rsn if subversion 1.5 has hit sid | 15:24 |
| jelmer | s/I'm// | 15:24 |
| Laibsch | yes, it has | 15:24 |
| Kinnison | johan: And that keyring contains the pubkey that you're signing your merge request with? | 15:24 |
| johan | user: "Johan Dahlin <jdahlin@async.com.br>" | 15:24 |
| johan | 1024-bit DSA key, ID 3F370F9A, created 2006-02-21 | 15:24 |
| johan | is being printed when I call gpg | 15:24 |
| Laibsch | jelmer: ii subversion 1.5.0dfsg1-2 Advanced version control system | 15:24 |
| johan | Kinnison: and gpg --list-keys includes a key called 1024D/3F370F9A, so yes that should work | 15:25 |
| Kinnison | hmm | 15:26 |
| johan | Kinnison: I'm not sure how I associate it with a branch, isn't enough to have keyring in the [DEFAULT] section of the configuration file? | 15:26 |
| jelmer | Laibsch: Yeah, that combination is known broken :-( | 15:26 |
| Kinnison | I have my keyring=... in [DEFAULT] yes | 15:26 |
| jelmer | Laibsch: You can either try 1.4.6 with 0.4.10 or 1.5.0/1.4.6 with 0.4.11 (0.4 branch) | 15:26 |
| Laibsch | jelmer: Do I need to compile stuff or can I just apply a patch? | 15:26 |
| Kinnison | johan: In your section for the locations, do you have a committers= line? | 15:26 |
| Laibsch | I'll try subversion 1.4 | 15:27 |
| johan | Kinnison: nope | 15:27 |
| Kinnison | hmm | 15:27 |
| Kinnison | try this... | 15:27 |
| Kinnison | in [DEFAULT] add | 15:27 |
| Laibsch | But IIRC there were other issues | 15:27 |
| Kinnison | groups=johan | 15:27 |
| Kinnison | then underneath the [DEFAULT] section add: | 15:27 |
| Kinnison | [johan] | 15:27 |
| johan | Kinnison: it doesn't work even if I set verify_sigs to 0 | 15:27 |
| Kinnison | members=jdahlin@async.com.br | 15:27 |
| Kinnison | then in the [file:///....] section add: | 15:27 |
| Kinnison | committers=johan | 15:28 |
| Kinnison | commit_re=.* | 15:28 |
| Kinnison | then you'll have everything I have, associated with committing permissions | 15:28 |
| Kinnison | It's possible you have to have the committers=... bit regardless of signatures | 15:28 |
| Kinnison | As I say, I set this PQM up several years ago | 15:28 |
| Laibsch | jelmer: yes, right. I remember now: http://rafb.net/p/oTdfdg66.html. God, I really loathe debian for its brokenness. | 15:29 |
| johan | Kinnison: okay, thanks I'll try that | 15:29 |
| Kinnison | good luck | 15:29 |
| johan | is there a way to make .bzr/branch/branch.conf persistent? | 15:29 |
| * Kinnison shrugs and points at the bzr devs :-) | 15:29 | |
| johan | heh | 15:29 |
| johan | do I need to edit the branch.conf file for each branch I want to use to submit to pqm? | 15:30 |
| jelmer | Laibsch: Did you keep python-subversion installed? | 15:30 |
| jelmer | Laibsch: (Since I assume you downgraded subversion?) | 15:30 |
| Laibsch | yes, but it still is 1.5 | 15:30 |
| Laibsch | I'll downgrade it, too | 15:30 |
| * Kinnison uses the pqm-submit plugin which can specify it on the commandline | 15:30 | |
| johan | Kinnison: that's what I'm using as well | 15:31 |
| johan | merge http://async.com.br/~jdahlin/bzr/kiwi/ file:///home/pqm/branches/kiwi/ | 15:32 |
| johan | Command failed! | 15:32 |
| johan | All lines of log output:Sender not authorised to commit to branch file:///home/pqm/branches/kiwi/ | 15:32 |
| johan | still the same thing | 15:32 |
| * jelmer meanwhile prepares 0.4.10-2 | 15:33 | |
| Kinnison | johan: Can you pop your pqm.conf on a nopaste for me to look at? | 15:34 |
| johan | Kinnison: http://pastebin.com/f3e8965ce | 15:35 |
| vgeddes | how does one add a working tree to a branch? I have forgotten the command | 15:36 |
| Kinnison | johan: OOI, is your pqm.conf in the right place relative to the rest (I.E. are you confident it *IS* being read?) | 15:36 |
| johan | Kinnison: yes, it's read, otherwise I'd get other error messages | 15:37 |
| johan | I pass in -c filename.conf when I run the command | 15:38 |
| Linnk | Hi :) How do I view a file as it was at a specific revision? Is it possible? | 15:38 |
| jelmer | Linnk: bzr cat -rREVISION FILENAME | 15:38 |
| Linnk | Ah, thanks! | 15:39 |
| vgeddes | anyone? | 15:43 |
| jelmer | vgeddes: "bzr co" | 15:43 |
| Kinnison | johan: I'm at a loss, I'm really sorry | 15:46 |
| johan | Kinnison: okay, thanks anyway! | 15:47 |
| johan | I'll ask Odd_Bloke when he's around. | 15:47 |
| jelmer | Laibsch: Any luck with 1.4 ? | 15:57 |
| Laibsch | it looks like it is slowly importing | 15:58 |
| jelmer | Laibsch: I'm about to upload 0.4.10-2 which will fix compatibility with subversion 1.5 | 15:58 |
| Laibsch | great | 15:58 |
| Laibsch | I'll put it in my ppa, I guess | 15:58 |
| vadi2 | I've told bzr to checkout a launchpad branch, but it's just sitting here doing nothing (and giving no message) at all for quite a while now.. any reason this can happen? | 16:24 |
| vadi2 | (it only made the folder but with nothing inside it) | 16:24 |
| rockstar | Is it a big branch? | 16:24 |
| vadi2 | I don't know how to tell. It's this one: https://code.launchpad.net/~chris-scutcher/colony/devel | 16:25 |
| vadi2 | It's not even giving me the progress bar though | 16:25 |
| rockstar | I know that rather large branches take a while to display a status bar. | 16:26 |
| rockstar | What version of bzr? | 16:27 |
| vadi2 | 1.5 | 16:27 |
| vadi2 | I'm subscribed to the bzr ppa, so should be latest available | 16:28 |
| fdv | uhm.. copy isn't supported, right? | 16:28 |
| fdv | is there any way to retain history if I need to make a copy of a file? | 16:29 |
| rockstar | Yea, it's still got the issue. It's a known problem, and there is a patch, but it apparently didn't get into 1.5 | 16:29 |
| fdv | ah | 16:29 |
| fdv | I saw some talk about it for 1.0 :p | 16:29 |
| rockstar | fdv, not you, vadi2 | 16:29 |
| vadi2 | oh | 16:30 |
| fdv | rockstar: ah, ok :) | 16:30 |
| vadi2 | rockstar: so do I just wait or wait for a bzr upgrade? | 16:35 |
| rockstar | vadi2, it'll branch eventually. I suggest you make a shared repo so when you branch again, it won't be so bad. | 16:37 |
| vadi2 | ok | 16:37 |
| fdv | hm. come to think of it, I need to do my copy in svn eventually anyway, and I guess it's just as easy (or easier) to just do it there and update to bzr | 16:38 |
| james_w | beuno: I'll be in on Tuesday | 16:48 |
| beuno | james_w, cool! you coming in to work all day? | 16:49 |
| james_w | yep | 16:50 |
| sabdfl | i have a loom on another server that I want to branch on my own machine, into an existing repo | 17:21 |
| sabdfl | bzr branch seems to lose the loom info | 17:21 |
| sabdfl | any suggestions? | 17:22 |
| jelmer | I don't have much experience with looms, but maybe upgrading your repository to the loom format will help? | 17:22 |
| jelmer | hmm, but looms use regular repositories.. | 17:24 |
| jelmer | sabdfl: apparently this is intentional | 17:25 |
| jelmer | what may work is just creating an empty branch locally, loomifying that | 17:25 |
| jelmer | and then pulling into it | 17:25 |
| james_w | sabdfl: have you run "bzr record" ever? | 17:31 |
| james_w | I think there may be a bug about this though. | 17:31 |
| sabdfl | james_w: where would i run "bzr record" ? | 17:35 |
| james_w | sabdfl: in your loomified branch. It records the state of the whole loom so that it can be branched, pulled, merged, etc. | 17:36 |
| Maslowski | Hello! I work on windows and I try to create a branch from the SVN repository "https://pa-do.svn.sourceforge.net/svnroot/pa-do/trunk", but I have the error : Not a branch. I have the SVN plugin installed. Any help will be welcomed. | 17:36 |
| james_w | I'm not sure why it's not done on every commit, I think it might be that the command is only temporary until it is automatic. | 17:36 |
| jelmer | Maslowski: Please try prefixing the url with svn+ | 17:36 |
| jelmer | Maslowski: e.g. svn+ "No instance for Monad (Either ParseError)" =/ | 17:37 |
| jelmer | whoops | 17:37 |
| jelmer | svn+https://pa-do.svn.sourceforge.net/svnroot/pa-do/trunk | 17:37 |
| Maslowski | I did it and still have "bzr: ERROR: Not a branch: "svn+https://pa-do.svn.sourceforge.net/svnroot/pa-do/trunk". | 17:41 |
| jelmer | Maslowski: does "bzr plugins" list the svn plugin? | 17:41 |
| Maslowski | yes, launchpad and svn 0.4.10 | 17:44 |
| jelmer | Maslowski: Any warnings when you run bzr that the bzr-svn plugin can't be loaded? | 17:52 |
| jelmer | Maslowski: If not, can you pastebin the contents of your .bzr.log file? | 17:53 |
| Maslowski | Pastebin considers the log file as spam | 18:06 |
| Maslowski | do you want me to open a bug and attach the file to it? | 18:08 |
| jelmer | Maslowski: pastebin.ubuntu-nl.org ? | 18:17 |
| thekorn | hi all, 'bzr commit' is creating bzr_log.* template files in my current working directory, is there a way to avoid creating such files or creating them in /tmp ? | 18:30 |
| Maslowski | jelmer: http://pastebin.ca/1062382 | 18:31 |
| james_w | tmp_fileno, msgfilename = tempfile.mkstemp(prefix='bzr_log.', | 18:34 |
| james_w | dir='.', | 18:34 |
| james_w | text=True) | 18:34 |
| james_w | hey thekorn | 18:34 |
| thekorn | hi james_w | 18:34 |
| thekorn | hmm, so it does not look like ;) | 18:34 |
| thekorn | I've used bzr commit for a few weeks now and have 30 bzr_log.* files in my working directory | 18:35 |
| james_w | "commit now can invoke an external editor in a non-ascii directory. (Watkins)" | 18:36 |
| james_w | bug 84043 | 18:37 |
| ubottu | Launchpad bug 84043 in bzr "commit fails to invoke external editor in non-ascii directory" [Medium,Fix released] https://launchpad.net/bugs/84043 | 18:37 |
| james_w | hmm, no, that's not right | 18:37 |
| thekorn | I don't understand how this bugreport is related | 18:40 |
| james_w | no, he removed the '.' while fixing it, and then put it back | 18:44 |
| james_w | thekorn: I'm not sure why the '.' is there. You can probably file a bug about it. | 18:45 |
| thekorn | james_w, ok, thanks for your help, I think I will file a bug because this really annoys me | 18:48 |
| jelmer | Maslowski, Does svn work on that url? | 18:48 |
| Maslowski | bzr branch http:... (without the 's' works. I'll try later with svn. | 18:51 |
| Maslowski | thanks a lot for your help | 18:51 |
| thekorn | james_w, sorry false alarm, I only have files like bzr_log.fZ2PE2~ which are created by my editor, so bzr is working as expected and removes the template file | 19:10 |
| Stavros | hello | 19:15 |
| Stavros | i've hit upon the "pop(): dictionary is empty" bug, does anyone know how to resolve it? | 19:15 |
| james_w | thekorn: ah, great, did you close the bug? | 19:19 |
| thekorn | yes | 19:20 |
| james_w | thanks | 19:20 |
| vadi2 | rockstar: how long is eventually? I left it over and hour and it hasn't moved :( | 19:25 |
| rockstar | vadi2, dunno. I know one branch took about two hours, but it has almost 7K of revisions and all the merge revisions | 19:26 |
| vadi2 | mk | 19:27 |
| bkor | 6 lines of Python, and it has a bug | 19:34 |
| Jc2k | lol :) | 19:35 |
| === mw is now known as mw|food | ||
| lifeless | hola | 21:17 |
| === mw|food is now known as mw | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!