[00:00] morning [00:16] with loom up-thread conflicts, do the *.THIS files refer to the lower of the two threads? [00:17] jml: IIRC, yes. Its switched because we use symmetry to make the operation faster [00:17] lifeless: ahh ok. how hard would it be to make them .UPPER and .LOWER, for example? [00:17] jml: patches appreciated [00:18] jml: (I don't know) [00:18] or ., I guess. [00:32] * igc breakfast [01:09] poolie: ping [01:09] http://bundlebuggy.aaronbentley.com/request/<1214359843.1536.41.camel@lifeless-64> <- I'm blocked on that; igc has commented but neither as tweak or resubmit [01:30] I use a shared repo with no trees [01:30] and use cbranch most of the time [01:30] however now I need to make a new checkout of someone else's branch [01:31] and I want to use --hardlink [01:31] what's the magic? [01:31] EPARSE [01:31] checkout --lightweight --hardlink ??? [01:31] lifeless: did the last bit help? [01:31] thumper: is branch location on your local disk ? [01:31] yes [01:32] uhm. I don't know that co --lightweight knows about hardlink [01:32] but the branch has no working tree [01:32] hm, ok [01:32] then there is no point [01:32] I'll just use the lightweight [01:32] can't hardlink to files that don't exist [01:32] thumper: hardlink is only relevant for working trees, it doesn't hardlink history [01:32] I was hoping that there would be some magic where it could link to trunk if it knew the file was unchanged [01:33] thumper: uhm [01:33] I have a working tree of trunk [01:33] thumper: cp -al trunk foo; cd foo; bzr switch otherbranchname [01:33] bzr col it is (another alias :-) [01:34] ETOOMANYCMDS [01:35] lifeless: I'm just wrapping up that review now. [01:36] igc: thanks [01:39] lifeless: there were some questions buried in my comments. Can you reply to those please? [01:39] sure [01:41] lifeless: pong [01:47] igc: done [01:47] poolie: nvm, igc is here today :) [01:50] What is the easiest way to see if plugin bzr-xmloutput is installed or not? Can I try something from the command line? bzr + ??? [01:50] nandersson: bzr plugins [01:51] Odd_Bloke, Thanks! I see bzr_xmloutput in the list! [01:51] nandersson: No worries. [01:53] lifeless: he'll be away in the afternoon but i'm trying to do reviews today [01:55] Am I able to checkout a bzr branch in Eclipse into my project? It seems that feature is not implemented [01:55] I'm using BzrEclipse that is [01:56] nandersson: you can, but its a bit weird, because of eclipse's project concept [01:56] beuno: do you know the trick? [01:58] lifeless, No, what's the trick? [01:58] just what is the limit on transferring revisions between rich root and other repositories? [01:58] lifeless, I do it from the command line from within the project folder? [01:58] (referring to Marius's mail) [01:58] does it depend on the revision or is it blocked altogether? [02:00] poolie: subtrees -> rich root is blocked on subtrees being used I think; rich root->plain is full blocked [02:01] poolie: because we can't tell 'made here' from 'converted' [02:07] In Eclipse I select "New Project" - "Bazaar" - "Branch as a new Project". In the next dialog I choose "Use existing branch location" but then the "next" button is greyed out and I can't go further. Is it a bug? Using Eclipse 3.4 and most recent BzrEclipse. [02:11] Hrmm.... seems it work if I use "New branch"... *investigating* [02:49] lifeless: That review is complete now - I've voted tweak fyi. The email should come through soon. [02:49] igc: thanks very much [02:55] spiv, Thanks for that memory analysis [02:56] jelmer: not a problem. I just wish I had a clear idea of what we can do about it... [02:57] spiv: not just because of the bzr push analysis but also because it explains Python memory usage analysis a bit [02:57] * spiv nods [02:57] Yeah, I learned a bit while doing it. [02:57] I'd like to be able to introspect CPython's memory management a bit more [02:58] It shouldn't be hard conceptually for CPython to tell me about all the arenas its allocated and what their stats are. [02:58] heh, the coloured diffs plugin for tbird does extremely strange things to that mail [02:58] mwhudson: heh. [03:02] spiv: have you trying compiling python --without-pymalloc ? [03:03] mwhudson: I haven't, and I don't want to :) [03:03] I think that is where I'm headed, though. [03:03] why not, it shouldn't be hard [03:03] (But not today, I have other things to do as well...) [03:04] Admittedly the last time I compiled Python was around 1.5.2. It's probably a little less icky than it was then. [03:04] But I don't really fancy tracking down random C extensions and things. [03:04] It's easy to compile it. The only problem is if you don't have all of its build deps installed, it'll lack readline, or bz2, etc. [03:04] spiv: it _really_ isn't hard [03:04] I'll probably be compiling it myself soon anyway, because I want to play with 2.6 [03:05] Anyway, why do you suggest --without-pymalloc? To see if the fragementation is better/worse? [03:06] yes [03:06] spiv- apt-get source [03:06] spiv: apt-get build-dep [03:07] lifeless: yep [03:07] mwhudson: Hmm, I'm not sure how that would help me, really [03:07] spiv: it would let us file bugs [03:07] :P [03:07] spiv: it would be data [03:07] I see. [03:07] Well, I have data. :P [03:08] spiv: i don't know that it would help with finding a solution necessarily [03:08] * spiv nods [03:09] * lifeless speeds up on the b+tree index [03:34] Is there any way to have a remote repository which you CAN update the working files by pushing (or similar) to it? I have a project I need to work on which I don't have shell access and would like to be able to push to it to update it. [03:34] well, repository is the wrong term.. branch I guess [03:35] meuserj: maybe the bzr-upload plugin might be useful [03:38] Verterok: ah, that looks perfect, thanks. [03:38] quit [03:39] bye meuserj === lamont` is now known as lamont [03:57] poolie: ping [03:57] (Pdb) print original_size [03:57] 5308576 [03:57] (Pdb) print len(contents) [03:57] 2564096 [03:57] pong [03:57] mwhudson, poking at your dont-hold-branches branch now, while I pack [03:58] beuno: cool, i'm still working on it a bit [04:06] mwhudson, haven't looked into bzr.lru_cache, but does that cache automagically? [04:07] beuno: it's like a dict [04:07] that throws items out when it reaches a certain size [04:13] well, code looks good, and from the looks of it, this should reduce RAM consumption a bit. Let's give it a spin... [04:14] not a good start: [04:14] File "/home/beuno/bzr_devel/loggerhead.dont_hold_branches/loggerhead/apps/filesystem.py", line 48, in __call__ [04:14] cached = self.root.cache.get(path) [04:14] AttributeError: 'BranchesFromFileSystemRoot' object has no attribute 'cache'[A[A[A[A[AA[A[A[A[A [04:15] right, serve-branches hasn't been tweaked yet [04:15] beuno: try pulling maybe [04:15] ? [04:16] mwhudson, I'm on revno 191 [04:16] * spiv -> lunch [04:16] hm [04:16] start-loggerhead works though [04:16] browsing the project has a small glitch: Exception: 'BranchWSGIApp' object has no attribute 'history' [04:17] spiv: when you return, I'd like to chat memory with you [04:18] mwhudson, other than those two things, code looks sensible to me, and it *feels* faster, although I don't have any facts to back that up [04:19] i'm working on the browse view now [04:19] may be my head is working slower [04:21] AfC: ping [04:22] thumper: hello [04:22] oh argh i hate the browse view [04:29] beuno: try rev 194, just pushed [04:33] mwhudson, fixed both issues, can't find more :) [04:33] beuno: ok, now see if the code makes sense :) [04:33] (i guarantee config.py won't) [04:33] I'm curious on to how this affects memory usage. Where is Peng when you need him... [04:34] it should be a bit better i guess [04:34] not massively [04:34] He's watching TV. :) [04:35] ah, view_data_by_name is interesting... [04:36] beuno: that's one word for it [04:37] oh [04:37] it's not bad, maybe with some docstring slapped on it explaining a bit of the logic would work [04:37] that reminds me [04:37] bzr-search_integration? [04:37] Peng, tv is bad for you :p [04:37] beuno: Yeah, I'm gonna die young. [04:38] * Peng eats some potato chips. [04:38] lifeless, well, that's in a mergeable-ish state. I'm not sure mwhudson is in a reviable-ish state though :) [04:38] Peng, you dare devil.... [04:38] maybe [04:39] "reviewable-ish" state is probably what I meant, but since I'm already making up words... [04:41] mwhudson, if this fixes the problem with too many branches open, some explanation in config.py should be good enough, IMHO [04:42] beuno: ok, thanks [04:42] * mwhudson writes some docstrings [04:42] maybe even try to get the guy with the 100% CPU bug to give it a spin [04:42] you know, make him break his server before you break LP :p [04:43] damn, still haven't started packing [04:44] igc: the pb thing is tricky [04:44] igc: passing it to the child - and each child will do 0..total [04:45] for total == what the child has [04:45] lifeless: yes, it's ugly [04:46] not passing it the child means the pb only shows the progress of local revisions [04:47] it's almost like you need to pass through an offset and total so the one pb can just keep stepping [04:47] igc: also, get_sha1s - [04:48] igc: its part of the overall 'VersionedFile is dead, long live VersionedFiles' [04:48] igc: agreed on the pb thing - thats the sort of tweak that would work [04:48] wrt no NEWS you mean? [04:48] igc: yes [04:48] ok [04:48] igc: we can list every single method if wanted, but its essentially everything that broke in that space; highlighting get_sha1s isn't very useful IMO [04:49] agreed [04:49] cool [04:49] my concern is always plugin authors [04:49] happy for me to land this? [04:49] yes [04:49] wooo [04:49] looking forward to it :-) [04:50] lifeless: well done on this, being able to stack across formats will be pretty magic when it all comes together [04:51] igc: it is :) [04:51] igc: I've been playing with it [04:52] igc: I'm pushing the latest shallow-branches loom too [04:52] cool [04:53] ok, with that done, I'm going to go write a parser/reader for BTreeIndex's [04:54] lifeless: I'm heading off to the doctors soon for most the afternoon so I probably won't get much more reviewing done today sorry [04:54] igc: thats cool; I'll sweet talk poolie [04:55] lifeless: yep, I'm hoping poolie can keep you unblocked [04:55] it is his job :) [04:55] now, where is that plumbers friend [04:59] Eek, LH's memory usage is still going up a bit. [05:01] Peng: where are you looking? [05:01] Peng, even with mwhudson's new branch? :) [05:01] beuno: No, I haven't tried that. Want me to? [05:01] beuno: Should it be reasonably stable? And does serve-branches.py work? [05:01] Peng, https://code.edge.launchpad.net/~mwhudson/loggerhead/dont-hold-branches-open [05:01] Peng, "yes" and yes :) [05:01] Peng: yes, just pushed revision 195 [05:01] Those are some ominous quotation marks. :P [05:01] will probably merge to trunk soon [05:02] How soon? [05:02] in a few minutes [05:02] Oh. I'll wait then. [05:03] My Loggerhead setup uses a custom branch in ~/loggerhead, so I'm not sure how I'd try a different branch than trunk. [05:03] man, 1221 lines of diff [05:04] (And yes, it is a stupid reason not to try another branch, but I'm lazy. :D ) [05:06] Peng: serve-branches ../differnet [05:06] spiv: pingish (refreshing scrollback) [05:09] Peng: trunk revno 180 [05:09] it's landed [05:09] Okay. [05:11] Peng: when you said that the memory usage was going up, how much memory was it using? [05:12] mwhudson: It had gone from 101 to 102 MB. [05:12] Peng: oh [05:12] that's not especially exciting :) [05:13] I was surprised it hadn't stopped growing. [05:13] (given that it routinely uses upwards of a gig on launchpad, though that's old old code now) [05:14] Well, I'm on a 360 MB VPS, so it is concerning. :P [05:15] ok [05:15] Anyway, I'm using the latest trunk now. [05:15] do you know what revno you were on before? [05:16] The last one. [05:16] So, 179, I guess. [05:16] ok, so you had the streaming output [05:16] Yeah. [05:17] Streaming can't be used with compression, right? [05:17] Because that would really reduce bandwidth use.. [05:17] um, don't really see why not [05:18] get apache to do it ? :) [05:18] (because compression is a great way to break buggy browsers, and the apache modules have the workarounds well noted) [05:18] lifeless: I use lighttpd. 1.4 doesn't support compressing dynamic stuff, though 1.5 does. [05:18] Peng: there you go then :) [05:19] Peng: though, if they followed the spec, and didn't read mod_gzip etc from apache, expect problems :) [05:20] hm, it looks like paste.gzipper will stop the streaming from streaming indeed [05:20] lifeless: The only breakiness I know of is IE and CSS and JS? [05:20] Woah. [05:20] I'm still connected, right? [05:21] Peng: ye [05:21] s [05:21] I thought I wasn't. I was about to reconnect everything when it started working again... [05:21] lifeless: pong [05:21] spiv: memory usage; would a new index with an LRU cache help much do you think? (can we talk voice?) [05:22] lifeless: perhaps (and yes) [05:23] is that you? [05:23] it is [05:23] handset out of juice [05:23] Ah. [05:23] skype? [05:24] its a silly bug in the battery [05:24] yes skye [05:35] bbl [05:49] poolie: chatted with spiv; the memory from reading existing indices was a significant thing. [05:50] poolie: also - for my copy of python-in-bzr-packs: [05:50] Original aggregate index size: 39016345 [05:50] B+Tree aggregate index size: 7585936 [05:50] Difference: 31430409 [05:50] spiv: ^ [05:52] That's a huge improvement! [05:52] I hope the improvement in memory consumption is as good :) [05:52] it will be different [05:52] I'll need some pointers on string interning etc [05:53] wow [05:53] Interning strings is easy, at least. Just "intern(s)", it's a builtin. [05:53] Oh, rather "s = intern(s)" [05:55] spiv: whats the overhead? (why isn't it the default) [05:56] It's the default for string literals that look like python identifiers. [05:57] the overhead is looking in and storing references in a big-ass global dictionary [05:57] But Python doesn't automatically check every str you read from disk to see if it is already intern'd. I assume the cost is roughly similar to checking a big dict. [05:58] I'm a little concerned about the cost of running millions of keys through that [05:58] I am too, although from what I saw from my testing it wasn't a big cost. [05:59] It's definitely worth benchmarking it more carefully though. [06:02] The upside speed-wise is that string comparisons get slightly faster (s1 == s2 is quick if s1 and s2 are the same str, it's just a pointer comparison). [06:04] It wouldn't shock me at all if it was less of a win with B+Tree indices... [06:09] spiv: an open question to think about is making index creation use less memory [06:11] Hmm, yeah. [06:13] mwhudson, I'm off to bed, have to catch a plain in a few hours. I'll probably be fairly unresponsive the next few days, especially on IRC, I may do better with email. Hopefully, long hours on the plane will get me to finish setup and directory-templates [06:14] beuno: ok, sounds good, sleep well [06:14] i'm stopping for the day too [06:14] (no internet at home yet, should get connected tomorrow) [06:14] mwhudson, ah, so we can expect less mwhudson_'ns? [06:15] we shall see [06:15] wish you luck with that :) [06:31] AttributeError: 'KnitPackRepository' object has no attribute 'weave_store' [06:36] ah, fixed already [06:36] bob2: what plugin? [06:37] ah, search [06:37] :) [06:38] (doesn't happen with 3515) [06:38] bob2: 3515? [06:38] r of bzr.dev [06:38] oh, revno of bzr.dev? VersionedFiles hath landed:) [06:39] ah, piffy [06:39] well, spiffy [06:39] bob2: yes, massive API breaks R us [06:39] * spiv ducks out for a bit [06:56] So far, I think the dont-cache thing improved Loggerhead's memory usage, but I can't really tell. [07:11] At the least, it sent back a 490 KB page and is using less than 22 MB of memory. [07:11] So the point of that branch was keeping branches open and stuff, but still, that surprised me. [07:22] Anyone around for a quick question? [07:23] Is anyone around for a quick question? [07:23] catsclaw: Generally it's a better idea to ask the question. [07:23] I've never had much luck doing that. [07:23] You've obviously been in the wrong chanels :) [07:23] At any rate, I'm hosted on Dreamhost and I'm trying to use Bazaar. [07:24] How unfortunate. [07:24] I'm not familiar with dreamhost, but at worst you've got sftp access, right? [07:24] Yes. [07:24] Yes. But then I have to define shell access for every one of my users. [07:25] Correct? [07:25] Isn't it possible to restrict a user to sftp with no other ssh access? [07:25] yes [07:25] even better, use bzr+ssh, restricted [07:26] sabdfl: That would involve installing bzr on the server, which is more of a pain. [07:27] At the moment, all access is generated from a database, which dynamically writes an .htaccess file and the svn access file dynamically [07:27] I don't know of any way of doing the same with the ssh users and passwords [07:28] And because the ssh usernames have to be unique across the server, I couldn't have easy logins to the site. [07:29] Is there any way to share an ssh login, but keep the contributor's logins distinct? [07:29] With bzr, commit authors and ssh users are not related in any way. [07:29] Where do commit authors get set, and is that secure? [07:30] ~/.bazaar/bazaar.conf, or by running "bzr whoami" [07:30] And anyone can claim to be anything. [07:30] There's no way to include validation? [07:31] Peng: And presumably the next statement is "but you can GPG sign your commits" :) [07:31] Oh, right. [07:32] are you using svn over ssh? [07:33] I'm planning on using sftp [07:34] catsclaw: For SVN or for bzr? [07:36] bzr [07:36] catsclaw: So what protocol are you using for svn? [07:37] must be raw svn:// or you'd have the same spoofing potential as with bzr [07:38] It's http [07:38] how usable is the bzr webdav thing? [07:39] Not, at the moment. It requires 1.6. [07:39] I'm not sure, it's vila's thing (SUBTLE PING). [07:41] How do I uninstall a plugin, btw? [07:41] catsclaw: reverse however you installed it [07:42] catsclaw: if you used the plugins setup.py, it will have installed to python_lib_prefix/bzrlib/plugins/NAME [07:42] catsclaw: but if you installed via apt, use apt to uninstall, if you installed by branching into ~/.bazaar/plugins/NAME, just remove NAME from there [07:43] I did a bzr branch command from lp [07:43] Where did you branch it to...? [07:43] I don't know. I was sitting in the Bazaar plugin directory, but it didn't put it there [07:44] bob2: webdav is usable, the 1.6 requirement is a bit artificial, I haven't the resources to test it against 1.5 and nobody will care in a few weeks. I'm just trying to minimize my entropy :) [07:44] catsclaw: if you ran 'bzr branch lp:FOO' then it made a basename(FOO) directory in the directory you were in [07:44] Well, it did it in such a way that it doesn't show up in explorer or a command line [07:45] catsclaw: interesting :) [07:46] catsclaw: 'bzr plugins -v' will tell you where it is, if it's affecting bzr. [07:46] hi [07:46] not installing http[s]+webdav:// support (only supported for bzr 1.6 and above) [07:46] Unable to load u'bzr.webdav' in u'C:/Program Files/Bazaar/plugins' as a plugin b [07:46] ecause the file path isn't a valid module name; try renaming it to u'webdav'. [07:46] can somebody help [07:46] drxnele: Not without knowing what you need help with. [07:46] bzr push lp:~screenlets-extras-team/screenlets/screenlets-extras [07:46] bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Escreenlets-extras-team/screenlets/screenlets-extras/.bzr/branch/lock): Transport operation not possible: http does not support mkdir() [07:46] drxnele: 'bzr launchpad-login' [07:47] catsclaw: You should do that then. [07:47] C:\Program Files\Bazaar\plugins\webdav [07:47] Only the only thing listed there is Launchpad [07:47] No Launchpad user ID configured. [07:47] how to do this? [07:47] drxnele: Sorry, I meant 'bzr launchpad-login '. [07:49] meny thanks [07:49] it worked [07:49] I just deleted the plugins directory. I get the same error, and the same results from bzr plugins -v [07:49] vila: awesome [07:50] catsclaw: run bzr --version [07:50] catsclaw: it will tell you where the 'log file is' [07:50] catsclaw: delete the log file, then run the command that is showing an error, then pastebin (e.g. to http://rafb.net/paste) the contents of the log, and the output bzr gave [07:51] You shouldn't have deleted that directory... [07:52] I can reinstall it [07:54] http://rafb.net/p/7tqMoL85.html [07:55] catsclaw: so in C:/Program Files/Bazaar/plugins [07:55] Yes? [07:55] catsclaw: you would appear to have a directory called 'bzr.webdav' [07:55] catsclaw: and bzr is telling you to rename that to 'webdav' [07:55] catsclaw: please do that, then try again [07:56] Which I would do, if I had a directory "C:\Program Files\Bazaar\plugins" [07:56] I don't. I deleted it. [07:56] catsclaw: Are you on Vista, by any chance? [07:56] catsclaw: [ 6096] 2008-07-01 01:51:29.979 WARNING: Unable to load u'bzr.webdav' in u'C:/Pr [07:56] ogram Files/Bazaar/plugins' as a plugin because the file path isn't a valid modu [07:56] le name; try renaming it to u'webdav'. [07:56] catsclaw: that says that you do; please check :) [07:57] There wasn't a subdirectory except for "launchpad" there before, either [07:57] I am on Vista. [07:57] Right, it does some screwy stuff in Program Files. [07:57] All in the name of saving you from yourself, of course. [07:58] There is no subdirectory named "plugins" in the Bazaar directory. [07:58] I'm not sure what to suggest, but I think you're right when you say you can't see anything and bzr is right when it says there is something there. [07:58] well, try to search for bzr.webdav on your disk [07:59] but first look to C:/Users/catsclaw/AppData/Roaming/bazaar/2.0/plugins [08:01] Directory of C:\Users\catsclaw\AppData\Local\VirtualStore\Program Files\Bazaar\plugins [08:01] 07/01/2008 01:05 AM bzr.webdav [08:02] so there is a bug in bzr, which reports incorrect directory [08:03] More to the point, when I ran the bzr branch command, why did it extract things to the VirtualStore? [08:03] And not the directory I was sitting in? And shouldn't bzr know about that, and warn you? [08:04] bzr _should_ be told about it. [08:04] I'm guessing it's Vista playig tricks on you [08:04] Whether it actually is or not is another matter. [08:05] bzr was probably not allowed to write to C:\Program Files or something like that [08:05] It looks like bzr is triggering some of the "don't break permissions-ignorant code" workarounds in Vista [08:06] I'm sure that was it. [08:06] So you need to do whatever the vista equivalent of "sudo bzr branch ..." is. Presumably it has one. [08:07] I can launch a cmd window as an administrator [08:07] yay windows. [08:07] catsclaw: sorry, I didn't realise just how much Vista gets in users way :) [08:07]