[00:24] mwhudson, someday, we'll need to clear out all those merge proposals for loggerhead [00:24] I feel very bad for all the unused code :( [00:24] morning [00:25] is it possible (via bzr-svn) to set a file property [00:26] beuno: yeah, me too [00:33] * hazmat wonders if a web browser on a bzr repository can be fast [00:39] I feel so fumble fingered on this new keyboard [00:41] lifeless: Is that your new envy-inducing laptop of supreme power? [00:41] yes [00:41] its not actually /that/ fast [00:42] as its a mobile edition, its relatively slow clock rate (2.13Ghz, idling at 1.2Ghz) [00:42] but the memory is really nice [00:42] and the SSD is pretty zippy [00:42] And it's quad-core, isn't it? [00:42] bzr selftest --parallel=fork took 6 minutes [00:42] 2 core, with threads so linux sees 4 cpus [00:44] Aaah. Still, 8gb of ram must be all sorts of fun. [00:44] yes [00:44] once i finish bugfixing ubuntu-vm-builder I'm going to make a lucid VM for lp patches [00:45] I've got 20G free, which is strange [00:45] I had a 60GB disk in my old laptop [00:45] rsynced across, and I have 86G used === verterok_ is now known as verterok [00:46] there is 5 GB in a recovery partition I didn't have the heart to blow away, and 1GB in swap, just in case it really wants it [00:47] What laptop is this? [00:47] Meths: my new one [00:48] make/model? [00:48] x201s [00:48] i7 640, 8G ram, 128G samsung SSD [00:49] pretty sweet [00:49] yeah :) [00:50] a separate vm so that it doesn't mess with your general system configuration? [00:50] yeah [00:50] I dont' want pgsql and apache running when I'm flying to $destination [00:50] and i'd forget to shut em all off if I had them installed-and-running by default [00:50] mm me too [00:51] is it possible (via bzr-svn) to set a file property [00:56] hazmat: no === jelmer_ is now known as jelmer [01:35] james_w, we'd especially like to get it in for https://bugs.edge.launchpad.net/bzr/+bug/521989 [01:35] Ubuntu bug 521989 in bzr "errors when importing WorkingTree on a thread due to signals" [Undecided,Confirmed] [01:36] ah, hi [01:36] is it bugfix only? [01:39] our x.y.z, z>0 releases will always be bugfix only [01:39] poolie: could you send me a mail and I will look tomorrow? IRC is too easy to forget. [01:39] fsvo 'always' i guess :) [01:39] should be a 2 minute job for me in that case [01:39] thanks, i will [01:39] yeah, there's bugfix an there's bugfix :-) [01:56] sent [02:00] loggerhead needs alot of love [02:02] hazmat: yeah [02:02] mwhudson, is there anyone with dedicated time on loggerhead? [02:03] hazmat: as much as anyone, it's me, but i've been doing other things lately [02:05] doesn't max? [02:05] doesn't max what? [02:06] poolie: true [02:06] have some time on loggerhead [02:06] i don't know if that's still true [02:12] a couple things worth looking at.. switching out to chamelon for page templates, use an aggregate js file, slimming down the html by using css. [02:12] Another new templating language? Sounds fun. [02:12] Peng: it's another implementation of the same one [02:12] its a page template engine, almost entirely compatible with the existing templates [02:12] Oooh. Neato. [02:12] god knows simpletal isn't very nice [02:13] its mostly faster because it compiles out to python code, instead of a using a template engine interpreter [02:13] FWIW, I wrote code to use Yahoo!'s aggregate JS file for YUI. Nothin' for Loggerhead's JS, though. [02:15] it would be nice if loggerhead didn't have to scan the repo and (re)build a cache to serve, but its not clear if that can be worked around, i assume that's mostly to avoid xml parse [02:16] hazmat: we don't use xml these days [02:16] hazmat: Patches welcome. :P [02:16] hmm.. so perhaps the loggerhead whole history cache is uneeded [02:16] Seriously, though, re-evaluating that is on the to-do list. [02:16] i notice trac-bzr doesn't bother with it.. it actually seems reasonably fast on a small repo [02:17] Not all repos are small. [02:17] Peng, i no.. i'm using the launchpad repo as my test case for performance analysis of loggerhead. [02:17] s/no/know === mnepton is now known as mneptok [02:17] <3 [02:59] is there a way i can see what a pull will bring in without actually doing it [03:00] hazmat: "bzr missing" [03:00] Peng, thanks [03:01] hazmat: That shows what both pull and push would do. See "bzr help missing" for the arguments to pass if you only want to see one or the other. [03:01] poolie: pm? [03:03] Eep. [03:04] I broke poolie. :( [03:06] Now you have to take his place. [03:19] i looking at bug #304320 seems easy enough to add --clean-obsolete-packs option [03:19] Launchpad bug 304320 in bzr "bzr pack should (optionally?) delete obsolete packs" [High,Confirmed] https://launchpad.net/bugs/304320 [03:21] in order to actually delete the dir contents i am thinking of adding an additional parameter to transport.delete_tree that allows skipping delete for container [03:21] http://pastebin.com/JbaQhzxD [03:21] this should ensure that if the operation is terminated for some reason .bzr/repository/obsolete_packs folder is still there. is this a reasonable approach? [03:30] parthm: I think that's reasonable. You should add a per_transport test for the new param. [03:30] mm [03:30] spiv: thanks for the pointer. i will add the per_transport tests. [03:30] there is functionality to delete the contents of obsolete_packs already [03:31] Please don't use the transport api to get at the private functionality of the repository - use that existing code instead. [03:32] Hello. How to use keywords plugin? I can't understand where do i need to place rules file [03:32] lifeless: where can I find this function? bzrlib.repository? [03:37] parthm: bzrlib.repository.repofmt/pack_repo.py - somewhere in there [03:37] obsolete packs is cleaned out when we do a pack - right before we do the pack. [03:37] lifeless: i see a private method, repofmt.pack_repo._clear_obsolete_packs. [03:37] yup [03:37] its a private task :) [03:38] add a parameter to the pack() call - something like 'assume_disk_will_write_immediately' or the like - its very risky deleting obsolete_packs folder, we really don't want people using this in API code in a casual manner [03:38] its particularly unsafe to use over SFTP/HTTP/NFS [03:39] lifeless: i agree, i have added this to the pack command help. [03:39] http://pastebin.com/JbaQhzxD [03:39] assume_immediate_write sounds like a good way to do it. [03:41] parthm: on the transport change, which might be nice in and of itself, how about 'children_only' rather than 'skip_container' [03:41] container isn't used elsewhere in the docs for transports [03:41] yes. children_only sounds good. maybe i should file it as a bug so it can be tracked separately. [03:41] sure [03:42] i was wondering if it makes sense to have a --clean-obsolete-packs-only option. pack can sometimes be time consuming. this would give the user to just remove obsolete packs without going through pack process. [03:44] sure [03:44] there may be a bug on that even [04:02] I notice that only RepositoryPackCollection has a _clean_obsolete_packs method and not KnitPackRepository. both have the pack method. whats the different between the two? [04:05] RepositoryPackCollection is not an implementation of the Repository interface [04:05] It's an implementation of ._pack_collection of (pack format) repositories. [04:05] So, the difference is different layers. [04:08] spiv: ah. i get it. so repository.pack internally maintains _pack_collection which it calls pack on. thanks. [06:04] Anyone know off hand the Subversion equivalent of `bzr revert`? Is there one? [06:05] AfC: svn revert -R . ? [06:06] hm [06:06] oh [06:06] how did I not see that. Grrr [06:06] sorry. Thanks mwhudson [06:14] mwhudson: 'bzr revert' [06:14] Yeah, use bzr-svn. :D [06:55] i am planning to add tests for bug #304320 to tests.blackbox.test_pack http://pastebin.com/C51qWKUH [06:55] Launchpad bug 304320 in bzr "bzr pack should (optionally?) delete obsolete packs" [High,In progress] https://launchpad.net/bugs/304320 [06:55] is the pack operation guaranteed to generate packs? [06:56] i am thinking of doing a transport.list_dir() and making sure its len is 0 [06:56] with --clean-obsolete-packs [07:03] parthm: its not guaranteed, no - but pragmatically thats fine [07:03] just do two commits, then a pack. [07:03] (because one commit would be fully packed already) [07:04] if, in future, we change bzr to auto clean when we can tell things have hit disk or whatever, we can change the test. [07:05] lifeless: right now when are the obsolete packs cleared? [07:05] parthm: when bzr packs [07:06] lifeless: ok. i will go with the two commits approach. thanks. [07:32] hi all! [07:35] vila: hi [07:40] is there a way to put a print in a test case and view it? selftest -v doesn't seem to do it. [07:44] parthm: if you're running blackbox tests, keep in mind that stdin/stdout/stderr are redirected.... [07:45] parthm: which also means you can't put pdb breakpoints in the code run by the inner run_bzr [07:46] vila: yes. i am using the blackbox tests. right now i just dump the info i need into a temp file but i think that a very crude way. [07:48] parthm: try to write whitebox tests instead :) [07:48] vila: ok. thanks :) [07:49] parthm: they are generally far more precise and easier to debug too :) === dcoles_ is now known as dcoles [08:15] jelmer_: Just to check I'm understanding you correctly with that bug, bzr serve --git _can't_ serve bzr branches? Only bzr-git ones? [08:43] hi vila [08:43] hi Ian [08:54] * igc dinner === nlisgo_ is now known as nlisgo [09:03] dcoles: yes [09:04] jelmer_: Ah. OK. [09:05] Then my other bug was when you try and serve git branches in a shared repo [09:05] I'll make a working test and then report that. === weigon_ is now known as weigon === jelmer_ is now known as jelmer [11:56] lifeless: I just read your comment about the news_merge plugin in https://code.launchpad.net/~gagern/bzr/bug513322-first/+merge/22045 [11:56] Hadn't known there was such a plugin. Does pqm make use of it? I assume it does. [11:56] What got me worried was the fact that the launchpad merge preview reported conflicts. I guess this is difficult to avoid right now, because the per-branch configuration isn't versioned. So launchpad users would have to configure each of their branches, which requires a lot of UI and work. [11:56] I think it would be better if one could configure the plugin in such a way that it works on all branches. To me that sounds like an application of the proposed .bzrmeta directory. Has this been discussed before? [12:05] BTW: That config issue makes me think of another thing I've been repeatedly thinking about recently: handling of ZIP files. [12:05] There is quite a number of file formats out there that are ZIP under the hood, but handled as a single document by some application, and usually have a file name extension other than ZIP. Examples are Microsoft OOXML, Google KMZ, Apple iWork formats, JAR files, and so on. [12:05] I often would have wished for a plugin to handle these things as a single ZIP in a working tree, but as a directory of members inside the branch. I guess I'd wish for morege conflicts to cause directory layout in the working tree as well, until those conflicts are resolved. [12:05] I don't have the time to implement this, but I'd still be interested in your opinion. Do you think this useful? Feasible? How would you want to configure such a plugin? Can you think of use cases likely to cause trouble I haven't thought of yet? Do you know of any efforts in that direction? [12:22] * igc night === salgado_ is now known as salgado [12:28] hello, anyone here using zsh? [12:32] dipnlik: not me, but I'm still curious why you're asking. [12:33] MvG: i'm having autocomplete issues when i'm on a repository folder [12:34] I'm the one maintaining bash-completion-plugin. [12:34] cd ~/my-repo ; bzr st gives me an error [12:34] I haven't looked at how zsh completion works, but I would assume that it should be possible to extens my plugin for zsh if there is need and some help. [12:34] bzr: ERROR: Not a branch: "/Users/dip/my-repo/.bzr/branch/": location is a repository [12:35] * MvG is looking at the zsh completion script right now. [12:36] OK, the zsh completion works on file names, not only command arguments. In that case, sensible autocompletion is harder, and also slower because it usually requires a call to bzr. [12:38] dipnlik: If the path only contains a repo and no branch or working tree, then running the status command, the only completion to "st" that I can see, doesn't make too much sense, does it? [12:39] dipnlik: zsh does execute "bzr ls --versioned", which should give you the same error message. [12:39] Of course, if you want to print the status of some file in some subdir, that would be a different thing... [12:40] i'm on a repo with some branches on it [12:40] i only wanted to autocomplete the branch name for the bzr ls command [12:42] In my opinion, the zsh completion is either too clever, or not clever enough. [12:42] that's what I think too [12:42] For bash for example, I only complete command arguments, but not file and directory names, as for the latter the built-in completion tends to be better. Therefore this kind of problem doesn't occur with my bash completion. [12:43] s/command arguments/command options/ [12:43] that's nice [12:44] so, I think it's more a zsh problem than a bzr problem, right? [12:44] I think it's a problem of whoever wrote the zsh completion script. [12:45] Which seems to be Steve Borho in 2005. [12:45] ouch >.< [12:46] Judging from the log, the script is unmaintained since then. [12:47] isn't Steve Borho a TortoiseHG developer? :) [12:47] The bash script shipped with bzr is in an equally bad shape, which caused me to write the bash plugin in the first place. [12:50] luks: There is some evidence to that fact on the web, yes. Can't say I know, though. [12:50] yes, he is [12:51] so there is probably little interest in fixing the script :) [12:51] MvG: any chance of a simple hack to at least avoid the error message? [12:52] dipnlik: Sure: redirect errors to null in _versionedFiles: fileList=(${(ps:\0:)"$(bzr ls --null --versioned 2>/dev/null)"}) [12:54] MvG: i think I'll need more details to use that :( [12:54] OK, dipnlik. All I have is a bzr source tree checkout, which contains a file contrib/zsh/_bzr which in turn contains the completion instructions. [12:55] You should have a copy of that file somewhere on your system, probably in a path mentioned in $fpath. [12:55] You need to find and edit that file. [12:56] Lines 48-53 of that file describe a function _versionedFiles, where line 50 does a bzr ls invocation. [12:57] After the --versioned but before the )"}) you insert a space and 2>/dev/null [12:57] Then you restart your zsh, and see if things work. [12:58] will try that, thanks a lot [12:59] Out of curiosity: what makes you use zsh? [13:00] trying it out of curiosity and because it fixes my main problem with bash: the command history [13:00] let's say i have two bash tabs on terminal, one with tail something and other where I type all the commands I use [13:01] if I exit the "main tab" then exit the "tail tab", all history on the main tab is gone [13:02] dipnlik: "shopt -s histappend" should fix this for bash. [13:04] zsh promises to do other things better, but for now it isn't really THAT better [13:04] oh-my-zsh also makes some promises [13:14] MvG: oh, thank you for that! [13:14] The histappend? I think it should be standard on any system. It is on Gentoo. [13:15] yeah [13:15] I always hated that it overwrote the file, but I just accepted it as a fact [13:17] I have a 'parent' directory magically appearing. Is it from bzr? [13:17] appearing after what action? [13:17] it's not any stadnard bzr directory [13:19] i don't know. i just made another new repo and it did not happen. init add commit : are candidates. You answered my question, I think. [13:21] are bzr vs. git discussions allowed here? i'm still not that into any of these but git seems to be overly complicated [13:23] dipnlik: as long as they're discussions not flamewars :-) [13:24] dipnlik: we'd be happy to discuss the differences in features of both systems and the advantages/disadvantages [13:25] jelmer: yay [13:26] has someone published/posted comparisons of efficiency scaling with history depth and repository size? I know git did have trouble scaling to large repository sizes within a module [13:28] i've seen comparisons and maybe git is technically better, but bzr is targeted for users, and that's a GREAT advantage [13:31] problem is: "everyone" is using git :( [13:32] so I don't know if I learn both or if I go with the flow [13:34] dipnlik: There is a bzr completion script shipped with zsh (4.3.10 in my case) which seems to be different and slightly more up to date than that shipped with bzr itself. So maybe you should file a bug report with zsh, after ensuring your script actually comes from a plain zsh setup. [13:37] lifeless: wrt my messages somewhere up there: just filed https://bugs.launchpad.net/bzr/+bug/546899 [13:37] Ubuntu bug 546899 in launchpad-code "Use news_merge plugin for launchpad merge preview" [Undecided,New] [13:39] MvG: i'm on zsh 4.3.9, which comes with OSX. edited /usr/share/zsh/4.3.9/functions/_zsh as you told me and it at least doesn't show the errors anymore, it helped a lot :) [13:46] dipnlik: have you seen comparisons of the scaling behaviour? I'm thinking of a graph that shows how memory consumption and processing time vary with varying code size or history. [13:50] dipnlik: from my experience, most people from "everyone" that are using git don't *really* know how to use git [13:52] edakiri: no I didn't, not really into which is better on the long run but since I'm only starting with version control and don't have big projects, that's not an issue for me (at least for now) [13:54] luks: what do you mean? I think I want to *really* know how to use either git or bzr, just not sure which i'll definitely use [13:55] also, github looks really great, maybe that is why "everyone" uses git [13:56] dipnlik: I mean that most people using git are using git just because it's popular [13:57] no any other reason [14:01] luks: i'm using bzr because it seems it's easier but still not sure if I try to get used to git or not. what do you think? [14:01] it's nice to use popular tools sometimes [14:15] My biased experience on git vs. bzr: 1. git pickaxe approach for history examination is nice. 2. git having to add stuff before committing is annoying, but commit -a helps. 3. bzr commands are much closer to svn and therefore easier for newbies, I think. 4. bzr send feels much easier than git patch formatting stuff. 5. I like the clear distinction between repo, branch and working tree bzr offers, to each its own dir. That way you can have multiple bran [14:24] dipnlik: git allows you to very easily screw things up [14:24] dipnlik: other than that, it's not that bad [14:25] MvG: 1 and 4. i've no idea /o\ 2. here on bzr i have to add new files before commiting 3 and 5. agreed [14:25] dipnlik: after you fully understand bzr, it should be easy to use git [14:27] 2. only if they are new, not if they are just edited. The latter is much more frequent in most cases. [14:29] MvG: ouch, adding edited files is weird. is there a good reason for that? [14:30] dipnlik: git uses a thing called 'index' [14:30] it contains changes that are meant to be committed [14:30] you can change a file, git add it, change it again but only the first version will be committed unless you add it again [14:31] git add is really very different from bzr add [14:31] and diff compares indexed state to working tree by default, so after the add but before the commit, a diff without options shows you nothing. [14:31] hi, can someone explain this error / how i can fix it ? [14:31] bzr: ERROR: Revision {('filehandler.py-20100312144733-dlv7tjsgt7fubqdc-1', 'om@om-20100319173025-gugcm11qrsdlksij')} not present in "CHKInventoryRepository('file:///home/om/Ubuntu%20One/reprap/software/pyreplicator/.bzr/repository/')" [14:32] oly: What command did you execute? [14:32] i well i tried a merge it said my tree was out of date so i tried a bzr update [14:32] and got that message [14:33] oly: can you pastebin your whole session, starting at the first command causing the out of date error message? [14:34] http://pastebin.com/dKfL6323 [14:34] theres not really anything to it though [14:35] is there a way i can force a merge it may overwrite what ever is causing the issue then [14:36] oly: Can you also add the output of "bzr info"? [14:36] oly: As far as I can tell, you are on a lightweight checkout, and the branch associated with that checkout was modified in some incomatible way since you created the checkout. [14:37] http://pastebin.com/LGzyJrch [14:37] could be, i do move between ubuntu lucid and karmic so the versions of bzr are likely different [14:37] OK, my assumption was wrong. [14:40] oly: I guess I'd first make a copy of that whole directory, just to be safe. Then I'd try to create a lightweight checkout of the branch head: "bzr co --lightweight . prhead" or similar. If that succeeds, I'd diff those two. [14:42] oly: The diff should show you both differences in the working tree format, possibly caused by different bzr versions, as well as the differences you'd wish to commit. [14:43] hum it checked out okay [14:43] oly: Passing -Derror to commit will print a back trace, which might give us additional information as to what revision it expects and why it isn't there. [14:43] diff pyreplicator/ /home/om/Ubuntu\ One/reprap/software/pyreplicator/ [14:43] is that how i should do the diff ? [14:44] i usually use meld and am only comparing individual files [14:44] diff -ur pyreplicator pyhead [14:44] or prhead, or whatever you have named it. [14:45] I'd be particularly interested in anything mentioning the .bzr/checkout subdirectory [14:46] is that on the new checkout [14:48] It should exist in both places. [14:48] And differences might be an indication of what's causing your error. [14:52] jelmer: ping [14:54] bialix: hey [14:55] heya [14:55] http://pastebin.com/M9RCxdAD [14:56] jelmer: does bzr-svn supports tags a-la bzr tags? [14:56] does not look like theres anything noticably different other than the source files [14:56] which is why i am trying to commit them :p [14:56] jelmer: see Bug 546906 [14:56] Launchpad bug 546906 in bzr-scmproj "crash for svn branches" [Undecided,New] https://launchpad.net/bugs/546906 [14:56] jelmer: any suggestion how I should fix this in scmproj? [14:56] bialix: yep, it does [14:58] jelmer: apparently other_branch.tags.get_tag_dict() where other_branch is svn://xxx does not [14:58] well, i'm leaving, thanks a lot for the help everyone, i'll stick with bzr and bzr-svn :) [14:59] bialix: only if you have a branch layout for which it is not known where the tags should be [14:59] jelmer: oh [14:59] jelmer: cause Guessed repository layout: TrunkLayout(0), guess layout to use: CustomLayout(['trunk/libavcodec'],[]) [15:00] that's it? [15:00] bialix: TrunkLayout(0) puts all tags in tags/ [15:00] bialix: for a custom layout it's not known where to put the tags [15:01] jelmer: so... maybe I just should catch that error and suppress it? [15:01] oly: Those u1conflict files look suspicious to me. [15:02] Any idea where they might come from? How do they differ from those without the .u1conflict extension? [15:02] okay, i dont think there in the repository at leat they should not be [15:03] there cause when there is a sync error between my two computers [15:03] they are generally the same file but a different version that did not sync [15:03] oly: I guess some such sync error garbled your working tree or branch. [15:04] bialix: it depends on what you're trying to do :-) [15:04] ah, i did wonder if it could be todo with the file sync [15:04] bialix: if you're pulling from that branch, I would just ignore the tags [15:04] oly: Safe thing would be, clone your branch and apply the source tree diff manually, without touching the .bzr dir. [15:05] jelmer: I'm checking if I need to pull first [15:05] okay or maybe easier, can i just revert to the online copy ? [15:05] and hit save in my editor again for the newer versions and then commit ? [15:09] * bialix waves at amanica [15:09] hi bialix :-) [15:09] hi dude [15:09] oly: Revert to online using "pull --overwrite" might work, but I'd not feel as sure with that. [15:11] okay, will have a play see what else i can break :) [15:11] oly: In my experience, synchronization of bzr branches using other sync tools is a bad idea. Didn't work out for me with unison either. Sooner or later you happen to modify things at one end but forget the other, and then a file-based sync easily breaks stuff. I'd suggest synking using bzr pull instead. [15:12] I meant modify at both ends and forget to sync in between. [15:12] okay, [15:12] yeah i asked some one about it a while ago if it was likely to cause problem they suggest it would be okay [15:12] but apparently not :p [15:13] is should be if you keep things strictly sequential, but that's hard. [15:14] yeah, anyway fixed [15:14] i had a better idea [15:15] move the .bzr folder to tmp, then copy the .bzr from a newely checked out copy [15:15] then run the commit :) [15:16] That's fine. [15:16] simple and seems to work which is what i like :) [15:21] When a merge proposal into bzr.dev was reviewed "Needs Fixing" by one person and has status "Needs review", do I have to resubmit the proposal after fixing the issue, or should I simply wait? [15:22] https://code.launchpad.net/~gagern/bzr/bug513322-first/+merge/22045 in particular. [15:22] Thanks for the help by the way MvG :) [15:22] np [15:24] Um...I'm not sure. You can push again and the merge proposal will be magically updated. [15:24] You can also file a new merge proposal, and that will magically handle everything too. [15:28] Peng: thx. I noticed the magic update. I guess I'll wait a while, see if waiting is enough. After all, "Needs Fixing" sounds less problematic than "Resubmit", which is a possible review comment as well. === salgado is now known as salgado-lunch [16:07] Is it a bug that urlutils.local_path_from_url barfs on a "readonly+file://" URL? [16:28] Peng: I don't think it's the correct URL to use in local_path_from_url [16:28] readonly+ is the prefix for bzr transport [16:32] Ohh? [16:32] Hmm. [16:32] Do readonly transports have a copy of the URL without that prefix, then? [16:32] Plus, IIRC the prefix is kept in Branch.base. [16:40] Peng: IIRC readonly transport is the wrapper for plain transport [16:41] so yes, there should be copy of URL w/o readonly+ somewhere inside [16:56] jam: Do you think I should mark bug 546899 as affecting PQM as well? [16:56] Launchpad bug 546899 in launchpad-code "Use news_merge plugin for launchpad merge preview" [Wishlist,Triaged] https://launchpad.net/bugs/546899 [16:56] MvG: reasonable to do so, I'm not really sure what would be done about it [16:56] it is more that bzr's pqm setu [16:56] it doesn't really affect bzr-pqm itself [16:56] so on second thought [16:56] maybe add bzr [16:56] but don't add bzr-pqm [16:58] Hmmm... hadn't known there was a bzr-pqm in addition to "plain" pqm... :-) [16:58] ah, sorry [16:58] pqm is the robot [16:58] bzr-pqm is a plugin to submit to the robot [16:58] And the robot should be the more likely one to complain about broken news, right? [16:59] s/broken/conflicting/ [16:59] regardless, adding 'bzr' might be reasonable, but it is probably more of a sysadmin thing than a bug in the program itself [16:59] There is no sysadmin subproject, is there? [17:02] Come to think of it, it already DOES affect bzr, because news_merge is part of the bzr.dev source tree. === deryck is now known as deryck[lunch] === salgado-lunch is now known as salgado === beuno is now known as beuno-lunch === deryck[lunch] is now known as deryck === beuno-lunch is now known as beuno === radoe_ is now known as radoe [18:31] jam: hi [18:32] jam: So, BtreeIndex seems very slow adding new entries after ~200k entries [18:32] 200k entries? Are you doing something evil? :D [18:32] I would never do evil things. [18:33] You use libsvn. :P [18:33] So does Google. [18:33] And Google doesn't do evil. [18:34] Ergo, I don't do evil. [18:34] QED :_P [18:34] Ah! Your logic is flawless. [21:11] hmm.. trac-bzr performs just as poorly as loggerhead on large repos [21:11] worse actually [21:11] the cache isn't just there because i'm an idiot :) [21:12] mwhudson, its interesting to see how performant bzr can be for a web ui without building a complete secondary index [21:12] hazmat: the biggest problem is revision numbering [21:13] mwhudson, i've disabled the dir ancestry stuff (dir rev appears as latest of contents), and i'm running it through repoze.profiler atm... [21:13] mwhudson, yeah.. i think thats what i'm seeing now.. still not 100% though [21:15] hazmat: what version of trac-bzr? [21:15] MvG, trunk, with trac 0.11.7 [21:15] trying it out on the launchpad repo [21:16] 110k revs it looks like [21:16] page loads are about 10s when it touches bzr [21:16] jelmer: the code dumps data to disk [21:16] you can look at the builder parameter "dump keys at" [21:17] hazmat: OK, thats a large number of revisions for sure. What page are you referring to? [21:17] hazmat: there is this bzr-historycache plugin that might help [21:18] MvG, mostly any browser pages below the root.. but the timeline also but thats mostly because theirs a few k changesets in the last 30 days. [21:19] mwhudson, my end goal is to see if bzr can do a fast web interface, the first thing i'm trying to reason is if a cache is required for that [21:19] hazmat: OK, in browser my first bet would be dir revision calculating, but assuming you deactivated all effects of that, conversion of revids to dotted revnos is my next best bet. [21:19] hazmat: ok, i can tell you that you will have a problem with revision numbering for off-mainline revisions without some kind of cache [21:20] hazmat: My current belief is that it is, but in many scenarios a in-memory cache would suffice. [21:20] igc has a plugin for that [21:20] MvG, yeah.. mwhudson mentioned that as well.. it does appear to be that (revid->revno mapping) [21:20] lifeless: caching those revs? [21:20] jam: Thanks [21:20] jam: I tried to reproduce it with a trivial script but I can't for some reason :-/ === salgado is now known as salgado-afk [21:23] hazmat: If you want to dig closer into improving trac-bzr using caches, we should have a longer talk. [21:23] I've spent some time already thinking about how I'd do this, what kind of info I'd whish to cache, and what kind of features that'd allow for trac-bzr. [21:24] MvG, if it can't work without caches, i'm going to try and spend time on improving loggerhead, i'm definitely up for the discussion though [21:24] jam: Also, I'm interested in looking at using bzr-based formats for bzr-svn [21:25] jam: basically something like the revisions VF together with some bzr-svn specific indexes, how would I go about doing that? [21:25] MvG: yes [21:27] so, it depends [21:27] I'm working on refactoring the code to do something like that for annotations [21:28]