=== mw is now known as mw|out [00:13] poolie, lifeless, et al: how close is the branch that introduces branch7 to landing? [00:14] lifeless: http://bazaar-vcs.org/SmartPushAnalysis1.4 [00:27] bkor, more answers :D [00:35] hi [00:38] name: Hey. [00:39] hm does bzr auto merge whitespaces? like foo(bar, x) == foo(bar,x) [00:40] name: No, those two statements would not be equivalent. [00:40] No, it won't. [00:40] damn. to i can't fix whitespaces without risking conflicts [00:41] bzr makes no assumptions about the content of the files it protects [00:41] Some types of file that may be a big significant change. === BasicPRO is now known as BasicOSX [00:45] jam: do mysql use --fixes ? [00:45] name: you could write a merge plugin to handle that [00:46] lifeless: is it easy? [00:47] name: I'm not entirely sure :) [00:47] name: shouldn't be too hard if you are familiar with python though [00:48] i am [00:48] i am [00:48] sorry [00:48] any guide you would suggest? [00:50] that reminds me [00:50] of? [00:50] Odd_Bloke, what's the state of per-file merge algorithms? [00:51] jelmer: Currently all in my head. [00:52] Odd_Bloke, Heh, ok [00:52] so any tutorial on writing merge plugins? [01:00] jelmer: jam wrote a branch [01:01] name: I can point you at an example [01:01] name: http://bzr.arbash-meinel.com/plugins/per_file_remerge might be useful to examine [01:01] name: but I'm not aware of a tutorial as such [01:04] The requested URL /plugins/per_file_remerge was not found on this server. [01:08] oh [01:08] jam: ^ [01:37] morning [01:39] igc: Morning. [01:39] hi Odd_Bloke [01:41] hi igc [01:42] igc: What's the preferred way to refer to members the set { working tree, branch, repository } documentation-wise? Is there one? [01:42] hi lifeless. Want any benchmarking done on OOo today? [01:42] Odd_Bloke: control directory? [01:43] igc: please [01:43] igc: I'd love usertest run with --btree-plain [01:43] igc: also, is there a dc machine with usertest that I can tweak myself? [01:44] Odd_Bloke: do you mean 'tree, branch,repository are all X' or 'tree is X, branch is Y, repository is Z'? [01:45] Yeah, that was a terrible explanation on my part, let me give context. [01:46] 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] But I'd like to stay consistent with the rest of the docs (if there's anything to be consistent with). [01:47] Odd_Bloke: why do you feel the need to specify that much detail? [01:47] Odd_Bloke: specifically: [01:47] Odd_Bloke: tree is an object in a control dir [01:47] ditto branch and repository [01:48] but I think you mean 'If the url given does not have any of ' [01:48] ? [01:48] and the general thing that hosts these objects is a control directory. So - 'if no control directory was found' ... [01:49] Nope, I mean if the user hasn't specified which of to check, bzr will check all plural() that it finds. [01:49] 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:50] 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:51] poolie: what dc machine is running usertest again? [02:03] igc, i think that is orgadas [02:03] orcadas [02:28] jml: bzr branch lp:mysql [02:28] jml: please try this, and suggest where I should file the bug [02:30] lifeless: file it on launchpad-bazaar. [02:31] lifeless: and set it to High, Confirmed. [02:36] jml: bombs away [02:37] lifeless: I'll get mwh to have a look at it when he gets back. [02:37] woot, svn 1.5 will now recognize and show bzr merges \o/ [02:37] now if bzr only had merge tracking support... [02:37] *cherry* [02:38] wow nice [02:38] jelmer: congrats [02:38] jelmer: when do you finish uni ? [02:38] :) [02:44] lifeless: end of the year hopefully [02:46] but for now you're on vacation already right? [02:48] yeah, yesterday was my last exam for the semester [02:48] jelmer: sweet [03:00] poolie: you free now? that number better than skype? === mark1 is now known as markh [03:18] markh: either is fine [03:19] skype is a bit cheaper if that suits you [03:30] * igc lunch [04:04] igc, i got your annoyance mail, will print it now :) [04:04] and even read it :) [04:07] thanks poolie :-) [04:08] 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] lifeless: afaik mysql does not use --fixes [04:09] poolie: I also need confirmation that I can merge content filtering as an experimental feature after tweaking [04:09] jam: there is a blog post about how launchpad's bug references are wrong [04:09] jam: if they did use --fixes, we could be right :) [04:11] igc, are you confident it won't hurt anything if it's not activeL [04:11] ? [04:12] poolie: let me check that and get back to you [04:14] jam: Just resent that email. [04:20] man [04:20] writing correct code takes thought [04:22] writing *correctable* code takes an eye on job security. [04:23] thanks mneptok [04:25] anything for you, dear. [04:26] that's why they call it support :) [04:27] I don't want mneptok supporting me :) [04:28] thats what I have underpants for! [04:30] i wish *i* had underpants ... [04:43] ok, my annotate measurements were incorrect [04:43] i didn't have extensions built in one of the branches [04:43] :) [04:43] that's a factor of 10-15 right there [04:44] how can I view the log message for the last revision of a file? [04:44] jml: hmm, bzr log FILE | less [04:44] lifeless: :( [04:45] otherwise, programming i guess [04:45] programming is hard. [04:45] if programming were easy I wouldn't care about the last log message in the first place :) [04:46] this programming isn't hard [04:46] yeah. [04:46] * jml makes a note to write the relevant patch / plugin [04:47] b.repository.get_revision(b.repository.get_inventory(b.last_revision())[mumble].revision) or something [04:50] what [04:51] tree = b.repository.revision_tree(b.last_revision()) [04:51] jml, maybe we should make an lp faq for things like this [04:51] or something in the developer docs [04:51] wt.paths_to_fileids(PATH, other_trees=[tree]) (something like that, its a UI call) [04:52] poolie: hmm. [04:52] poolie: A FAQ's probably a good idea [04:53] poolie: particularly if the understanding is that some of the items actually represent missing features :) [04:54] mwhudson: generally, revision_tree is better than get_inventory [04:54] lifeless: oh right, yes [04:54] mwhudson: as revision_tree is richer, but ~= to create [04:55] lifeless: someone should teach loggerhead this at some point :) [04:56] jml, actually maybe a rst document would be good [04:56] because it could turn into a doctest and then be accurate [04:58] poolie: I like text files. [05:09] lifeless: i'm trying to come with a name for that method i said could be separated from annotate [05:10] poolie: ok [05:11] knit.get_parent_map_for_present_ancestors ? [05:12] what does it do? [05:14] http://pastebin.ubuntu.com/24904/ [05:15] is that method name a fair description of what it does? [05:16] sure [05:16] note that it gets both local and remote ancestors [05:16] 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:17] spiv: were you planning to merge your InterRemoteToOther patch today? pqm is free fwiw :-) [05:19] jelmer: ping [05:19] some error handling needed: [05:19] bzrlib.plugins.svn.tests.test_branch.WorkingSubversionBranch.test_fetch_dir_upgrade [05:20] Command terminated [05:20] bzrlib.plugins.svn.tests.test_branch.WorkingSubversionBranch.test_fetch_dir_upgrade [05:20] Command terminated [05:20] lifeless: what version of python are you running? [05:20] try "make gdb-check" [05:20] 2.5ish [05:20] jelmer: where [05:20] in the bzr-svn dir [05:20] quick poll: [05:21] what should 'bzr get lp://dev/é' do? [05:21] slap you [05:21] (i'm assuming "what it does now" isn't really acceptable) [05:21] lifeless: heh [05:21] jelmer: its in gdb [05:22] lifeless: sorry, try: "make gdb-check TESTS=bzrlib.plugins.svn.tests.test_branch.WorkingSubversionBranch.test_fetch_dir_upgrade" [05:22] then run [05:23] Program received signal SIGABRT, Aborted. [05:23] [Switching to Thread 0x2ae68f153cf0 (LWP 6033)] [05:24] #0 0x00002ae68ee23095 in raise () from /lib/libc.so.6 [05:24] #1 0x00002ae68ee24af0 in abort () from /lib/libc.so.6 [05:24] #2 0x00002ae692539d89 in ?? () from /usr/lib/libsvn_subr-1.so.1 [05:24] #3 0x00002ae69276c629 in apr_palloc () from /usr/lib/libapr-1.so.0 [05:24] #4 0x00002ae6918beddd in ?? () from /usr/lib/libsvn_delta-1.so.1 [05:24] #5 0x00002ae692bb096f in ?? () from /usr/lib/libsvn_fs_fs-1.so.1 [05:24] #6 0x00002ae69149722f in txdelta_call (self=0x18e51b0, args=, kwargs=) at editor.c:103 [05:24] if you want more, I'll pastebin [05:24] thanks, that seems similar to the issues berto- was seeing earlier [05:24] let me update then [05:27] jelmer: pulling is slow from your repo [05:27] I wonder if rich root pulls are using the pack optimiser :( [05:27] I suspect not [05:27] they are not [05:27] pushing is veeeery slow [05:28] far out [05:28] its doign install revisions [05:28] ahha! [05:29] (Pdb) source._format [05:29] [05:29] (Pdb) self._format [05:29] [05:29] which is to say [05:29] what's the difference between those two exactly? [05:29] your repository is subtrees [05:29] and my repo is rich root packs [05:29] ah, it probably predates the rich-root formats [05:30] hah hah: http://gould.cx/ted/blog/Bazaar_Power_Management [05:30] so [05:30] jelmer: align it up, it should be faster:P [05:31] jelmer: still dies [05:31] :-( [05:31] stack looks the same [05:31] lifeless: What exact platform/python/subversion versions? [05:32] (Since I can't reproduce it here) [05:32] amd64 [05:32] 1.4.6dfsg1-2ubuntu1 svn [05:32] 2.5.2-2ubuntu4 [05:32] python [05:32] thanks [05:38] Hi [05:39] hi Verterok [05:39] lifeless: hi :) [05:39] I'm playing a bit with the integration of bzr-search ;) [05:39] cool [05:40] and I have quick question: how can I get a revno from a revid [05:40] ? [05:40] have a look at revspec [05:40] ok, thanks [05:40] also there is some stuff on Branch [05:41] lifeless: FileTextHit are hits in the working tree or also includes text hits in the history? [05:41] only history [05:43] oh, I see... it would be great if I can integrate that just like the text search provided by eclipse [05:43] is there a way I can get the line, length and/or offset of the text hit? [05:44] not at the moment [05:44] its why the summaries are a little kludgy [05:45] mlh_: lol [05:51] 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] Verterok: nice [05:52] * Verterok still needs to learn a thing or two about eclipse search API [05:55] Verterok: I demoed it last friday [05:55] Verterok: had trouble with eclipse and workspace locking and stuff [05:55] :( [05:55] oh, that's bad :( [05:55] the search bit worked [05:56] cool [05:57] ok, real world data [05:57] which which is the new index: [05:57] real 0m13.602s [05:57] user 0m13.053s [05:57] sys 0m0.200s [05:57] or [05:57] real 0m17.347s [05:57] user 0m15.173s [05:57] sys 0m0.352s [06:05] igc: Hmm, I thought I merged that yesterday... I wonder where the success/failure from pqm went? [06:05] oh hey, pqm does that you you guys too? [06:06] spiv: it's not there as best as I see. [06:06] (using log --short on bzr.dev) [06:06] at the moment its teh autopack bug doing that [06:09] * spiv resubmits [06:09] igc: thanks for noticing :) [06:17] spiv: the credit belongs to BB, not me! http://bundlebuggy.aaronbentley.com/?selected=mine [06:19] igc: so, ooo ? [06:23] 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] [I realize the search for the ideal test case has long been a topic] [06:24] 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] AfC: you're right. [06:25] there are multiple dimensions ... [06:25] lots of files [06:25] deep history [06:25] complex history [06:25] my OOo and moz trees cover the first 2 well [06:25] igc: sure [06:26] The only public projects I'm aware of with all three would be the Linux kernel and MySQL [06:26] I'm grabbing a copy of mysql now fwiw [06:26] Nice [06:31] 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:49] rockstar: bzr upgrade --pack-0.92-subtree [06:49] wheee [06:49] lifeless, what if I want to lose the subtree support? [06:49] 28609 robertc 18 0 2111m 1.8g 1468 D 0.3 89.6 7:34.69 python [06:49] You might be able to upgrade to rich-root-pack, right? [06:49] rockstar: 'bzr pull svn://' [06:49] * Peng goes to bed. [06:53] rockstar: (you can't downgrade model data, subtrees store more data than rich roots) [06:57] poolie: you back ? [07:04] spiv: know of a python module to parse proc/pid/statm ? [07:05] crap! holy! [07:05] robertc@lifeless-64:~/source/python/python-btree$ du -sh .bzr/repository/indices/ [07:05] 4.6M .bzr/repository/indices/ [07:05] robertc@lifeless-64:~/source/python/python-btree$ du -sh ../python-packs/.bzr/repository/indices/ [07:06] 38M ../python-packs/.bzr/repository/indices/ [07:11] lifeless: back now [07:12] igc: wow that's really good! [07:12] poolie: thanks [07:12] lifeless: I don't, unfortunately [07:13] lifeless: although I think jam maybe had code to read it? [07:13] i have some more feedback, will send mail [07:13] looking forward to it [07:15] spiv: read it is easy :). [07:15] spiv: I just need to figure which like is vss [07:16] lifeless: actually... [07:17] lifeless: http://www.pixelbeat.org/scripts/ps_mem.py [07:18] lifeless: that code isn't really structured for importability, but it might be a useful reference [07:18] so, python via svn [07:18] 149M packs + 38M indices -> 149M packs + 4.6M indices [07:18] 187 -> 154 [07:19] That's a much nicer data:index ratio. [07:19] 33/187 shrink in repo size [07:19] 17% [07:20] lifeless: awesome [07:20] log time was indisinguishable [07:20] but they are fully packed so meh [07:21] howeveer, I'm now going to try to get a peak VSS reading [07:25] lifeless: maybe you should write a scriptlet that breaks a repository into chunks each of a random number of revisions [07:26] You could call it "bzr unpack" ;) [07:27] 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:28] spiv: I could [07:28] spiv: or [07:28] spiv: I could just use my 22G presplit test repo :) [07:29] spiv: ahh! [07:29] spiv: /proc/pid/status [07:43] spiv: http://rafb.net/p/EbcdpJ48.html [07:43] spiv: give that a spin. [07:44] VmPeak: 296680 kB [07:45] That looks like a handy patch. [07:45] and [07:46] VmPeak: 300408 kB [07:46] so [07:46] I'm amazed how much memory log uses up [07:49] 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] this is true [07:50] so the question is when is high VM and low resident good [07:50] answer - never :) [07:50] I wonder if VmHWM is any better? Pity my man proc(5) doesn't describe these fields. [07:50] so [07:50] I put a pause in there [07:50] I see this: [07:50] 15212 robertc 20 0 299m 88m 5856 S 0 4.4 0:27.62 python [07:50] VmPeak: 300576 kB [07:50] VmSize: 298116 kB [07:51] VmHWM: 93068 kB [07:51] VmRSS: 90508 kB [07:51] lifeless: if you can use valgrind there is the massif plugin [07:51] lifeless: it tracks heap-allocations over time [07:51] weigon: we can [07:51] weigon: I wanted something incredibly lightweight though [07:52] http://developer.gnome.org/doc/guides/optimisation/Massif.html ... k [07:52] weigon: just a 'does BTreeIndex peak higher' [07:52] 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] lifeless: that seems to tally (90508/1024 ~= 88.3) [07:52] spiv: yes :) [07:53] AfC: http://lwn.net/Articles/230975/ sound promising [07:53] spiv: so I think the VmHWM is probably the immediately interesting thing [07:53] Agreed. [07:53] spiv: however, keeping VmPeak low is good too [07:53] * spiv nods. [07:53] here's another one I prepared earlier [07:54] 28609 robertc 18 0 2182m 1.9g 1432 D 0.7 97.3 8:18.83 python [07:54] spiv: r=spiv on that patch btw ? [07:54] should I NEWS it? add a guard for windows (but will it work on bsd ?) [07:54] lifeless: Just add a guard on the file existing, I think. [07:55] lifeless: I'm happy to have that merged, I think. [07:55] try: [07:55] status_file = file('/proc/%s/status' % os.getpid(), 'rb') [07:55] except: [07:55] pass [07:55] else: [07:55] sufficiently ugly ? [07:55] Yeah :) [07:55] Well, [07:55] Not a bare except. [07:55] bare except [07:56] No, just IOError [07:56] That should cover all reasonable exceptions, rather than e.g. KeyboardInterrupt. [07:56] Python's docs are pretty clear that "If the file cannot be opened, IOError is raised. " [07:56] committing [08:01] so anyhow [08:01] that 4G process [08:01] Virt + res is pretty high :) [08:06] weigon: the other problem is we need python backtraces on allocation pressure; and python allocates arenas no objects [08:06] lifeless: you can't disable for debugging ? [08:07] but yeah, that doesn't help with the python stacktraces [08:07] I really like to have a toolchain that can debug in production [08:07] it makes it a lot easier to fix something a user reports [08:08] 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] 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] igc: ok, see you online in weird timezones :) [08:09] glib2 also uses "slices" but you can disable that at runtime with G_SLICE="always-malloc" [08:09] (I wonder if it's possible to override that with an LD_PRELOAD hack?) === brilliantout is now known as brilliantnut === brilliantnut is now known as brilliantout [09:19] ToyKeeper, ping [09:25] 'lo [09:25] jelmer: yes? [09:25] ToyKeeper, Do you still have that sawfish branch around? [09:25] Yeah. [09:26] I was actually just looking again at how best to convert svn to bzr without losing tags... [09:26] 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] I'll check... [09:27] ToyKeeper: Try the latest bzr-svn revisions, it sets real bzr tags now [09:27] (although it doesn't pull in the revisions they point at yet) [09:32] Well, it's running. I'll let you know. :) [09:33] 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] you need a rich root repo [09:33] jelmer: BTW, are you wondering about memory use on the sender or the receiver? [09:34] ToyKeeper, both, actually (I'm wondering if the high memory use is in bzr itself as well) [09:35] spiv, ping [09:41] jelmer: Okay. 3 minutes. 88 MB on the client, 24MB on the server. [09:41] ToyKeeper, Hmm, so at least that's not the problem. Thanks. [09:42] (client was the same bzr.dev which spiked in the bug report... server was bzr 1.5) [09:42] I doubt it matters, but 'bzr serve' was proxied through bzr_access. [10:08] I am trying to check an svn repo into bzr [10:08] I am seeing some strange issues [10:08] http://rafb.net/p/Y0s6oC57.html [10:08] svn itself works fine, though [10:09] any idea? [10:10] Laibsch: does something like mtr actually reach that host? It seems more like general networking problems. [10:10]