[00:56] Good morning [00:57] news_merge should be active on PQM now [01:12] hiya spiv [01:12] yay! [02:07] mkanat: hi? [02:07] poolie: Howdy! [02:07] hi there [02:07] are you free to work on some loggerhead bugs now? or perhaps already doing so? [02:08] poolie: Yeah, I could do some. :-) [02:08] poolie: Not at this exact second, but probably today or tomorrow. [02:12] ok [02:12] i was just reminded by seeing a notice of another hang the other day [02:12] wbn to either get to the bottom of it, or go to a multiprocess thing [02:12] or both [02:13] poolie: Yeah, for sure. [02:13] poolie: The multiprocess thing is a big project, though. [02:17] well, actually fixing things is more satisfying [02:17] poolie: Absolutely! [02:17] poolie: I've done so many small, focused hang fixes that would all have been obsoleted if we just had a better architecture. [02:18] hm [02:18] poolie: Except for one deadlock, the hangs that I've fixed haven't really been hangs--they've just been the system getting overloaded. [02:18] i wonder if someone else could work with you on changing the process architecture [02:18] hm [02:18] poolie: Ultimately I suspect it's something that would be most efficiently done by one developer. [02:18] perhaps [02:19] poolie: The codebase isn't so large that it would have to be a team effort, I think. [02:19] it would be nice to at least get review of it by someone else [02:19] poolie: I'm not saying that that one developer has to be me. [02:19] poolie: Oh, absolutely. [02:19] poolie: One reviewer and one developer would probably be a good match. [02:46] mkanat: ok, let's do it [02:46] poolie: Sweet! [02:46] poolie: I'll start feasibility studies probably today or tomorrow. [02:46] if possible keep it isolated in wsgi stuff as much as is sensible so we can switch that layer later [02:46] and let's think about supportability/traceability stuff [02:47] like keeping oops reporting, perhaps something to show where time is spent [02:47] but mostly, see if you can get the basic switch done [02:47] have fun [02:47] don't go silent [02:47] poolie: Okay. :-) [02:48] poolie: Because we're switching from a threading model to a process model, though, there will be a lot of stuff that isn't in the WSGI layer. [02:48] poolie: Since we will be removing locks, and we can't share variables anymore. [02:48] ok [02:48] perhaps you could explain this in a mail rather than to me [02:48] probably we should talk about that in mail [02:51] poolie: Okay. I will as soon as I get further into finding out what's actually require.d [02:51] *required [03:20] I'm thinking of wrapping the docstrings in builtins.py in gettext calls in order to enable translation of at least the help text. Am I overlooking anything obvious? [03:21] It should work for class docstrings; would have to be more complicated if we used method docstrings in the help output. [03:25] performance [03:27] it depends on what you mean [03:27] if you mean 'pass the help text to gettext when rendering help' - that should be fine. [03:28] lifeless: well you still need to mark the strings for translation. [03:28] why? [03:29] lifeless: So that they end up in the POT file? [03:29] there are other ways of doing that [03:29] we know all things to translate via introspection [03:30] jbowtie: _() will run afunction for every string at load time for the system, its a terrible overhead [03:30] I'd be happy to know what those are, all the programs I translate use gettext. [03:31] jbowtie: for command in commands: text = command.help(); line = command.run._im_co.__line__ ... [03:31] * lifeless is handwaving [03:32] jbowtie: in C _() is free because the code is not executed unless you go down the code path; thats not the case for python. [03:32] static attributes are executed at module time. [03:32] lifeless: Well then maybe we shouldn't be using docstrings for documentation? [03:33] I'm just concerned that currently I can't translate bazaar via Launchpad. [03:33] jbowtie: why not? they are designed for it [03:33] jbowtie: so, definitely doable; some glue needed. [03:34] Handwoven glue that will need to be run every time a docstring changes? [03:35] I'm just dubious, everything ends up getting patched to gettext eventually, or programs end up not getting translated. [03:35] Well, like whatever bit of gettext that extracts _() syntax into POT files needs to be re-run when those strings change. [03:36] It's just that rather than having a "extract _() calls in source into list of translatable strings" step, we'd have "run $handwave that has no runtime penalty in Python" step. [03:38] lifeless: Is Launchpad using a multi-threaded or multi-process server, right now? [03:38] mkanat: multi threaded [03:38] We could even look at automating that step, e.g. PQM updating the set of strings to translate in Launchpad after every merge. [03:39] lifeless: Okay. Have you guys done any investigation on moving to multi-process, or are you scaling OK with multi-threaded? I'm starting to investigate possibilities for loggerhead. [03:40] mkanat: we have 12 or so machines running lp itself [03:40] All right, I'll go look at the source for xgettext for a while. [03:41] mkanat: I have concerns about performance with threads and am investigating single-threaded instances (one request at a time) - because we already have a solid layer 7 proxy handing stuff to the backends [03:41] we could point that at loggerhead very easily [03:41] mkanat: e.g. tell paste to use 1 thread only and run up 4 loggerhead instances [03:41] mkanat: no need, in such an approach, for any multi-process glue. [03:42] mkanat: I have a bias against multi process wsgi; U1 tried that had it was a fairly bad experience for them. [03:42] lifeless: So I've heard, but I didn't really get any details on what the trouble was. [03:42] me neither [03:43] anyhow the big thing for me is that we already have a multi-process multiplexing system [03:43] we don't need two. [03:43] for the launchpad deployment of loggerhead, that is. [03:43] lifeless: Hmm. [03:43] the simplest way to get one process per request is to drop the thread count to 1 and tell ha proxy to send to 4 instances (or however many we decide to use) [03:44] lifeless: That certainly would be less work. [03:44] lifeless: Although that doesn't get us process management. [03:44] mkanat: what does 'process management' mean [03:45] lifeless: Well, say, the ability to tell when a process is hung and kill it, and then spawn another process. [03:45] lifeless: It's something that could be done with sysadmin work. [03:45] lifeless: But it's nicer to just have it in the app. [03:45] ah, 'spawning' was the name of the thing that gave u1 grief, IIRC [03:45] lifeless: Right, that's the only major multi-process WSGI server. [03:45] lifeless: But it's been years since U1 used that, and there have been a lot of Spawning releases since then; it's a very active project. [03:46] long term I'd like to be able to share the bazaar.launchpad.net load with the rest of the servers; with safeguards for rogue stuff [03:46] but thats -long- term, we're nowhere near ready for that [03:47] lifeless: You mean make loggerhead part of the normal server pool? [03:47] mkanat: anytihng that makes it easier to switch between paste, paste-w/1-thread, spawning, and in-lpnet-appservers is a good investment [03:47] mkanat: yes, just another wsgi site in the app [03:48] in the middle tier [03:48] lifeless: Okay. [03:48] lifeless: Who would I ask about what the U1 problems were with Spawning? [03:48] what tz are you in? [03:49] lifeless: Pacific [03:49] America/Los_Angeles [03:49] statik: would be a good entry point [03:49] he's not leading the team anymore but he'll know who was involved [03:49] lifeless: Great, thanks. :-) [03:50] lifeless: So from your viewpoint on the Launchpad technical side, what you'd like to see from loggerhead is a framework that makes it easier to fit it into whatever WSGI configuration you want to use. [03:52] I think that that would be a wise thing to work on [03:53] I think fixing the hangs is important too, because a hang is a user not getting a response. [03:53] lifeless: The hangs are a scaling problem. [03:53] lifeless: Or a deadlock problem. [03:53] and I think fixing the performance is also important [03:53] lifeless: Both of which are fixed by having multiple processes. [03:53] mkanat: deadlocking on what? [03:53] lifeless: Depends. [03:53] lifeless: Last deadlock I fixed (it was several months ago) as I recall was in cache access. [03:54] so, bzr serve itself is threaded. [03:54] lifeless: I'm just saying in general that the hangs are either a performance problem or a deadlock problem. [03:54] mkanat: so by perf problem you mean 'not a hang, just slow' ? [03:54] lifeless: I mean either, really. [03:54] lifeless: Oh, yes, I see what you mean. Yes. [03:55] lifeless: It's so slow that it might as well have hung. [03:55] ok [03:55] and the actual hangs are generally deadlocks [03:55] lifeless: Well, there generally aren't actual hangs. [03:55] lifeless: I fixed one deadlock. [03:55] lifeless: Also, bzr itself is not thread-safe. [03:55] so [03:56] bzr needs to be threadsafe [03:56] or move to aprocess model for 'bzr serve', itself. [03:56] lifeless: That seemed like a pretty low priority, making all of it thread-safe to the degree that loggerhead would need. [03:56] mkanat: the thing is that we support 'bzr serve' so if loggerhead has an issue with bzr thread safety, so does bzr. [03:57] lifeless: Nobody runs a persistent bzr serve. [03:57] mkanat: yes, they do :) We get discussion from time to time. [03:57] mkanat: even if they don't, while we claim it as a supported feature... [03:57] mkanat: I'm not saying you shouldn't change loggerhead models [03:58] I'm just saying that poolie has a strong desire and incentive to have the core be solid and robust [04:02] lifeless: Okay. === timchen119 is now known as nasloc__ [04:11] lifeless: I didn't get the impression that global thread-safety across all of bzr was going to happen within the next few years. [04:12] lifeless: And even if you make "bzr serve" thread-safe, that doesn't make loggerhead thread-safe. bzr serve doesn't need to run the annotate code, for example. [04:12] At least, as far as I understand things. [04:14] mkanat: I'm not aware of many if any remaining unsafe things [04:14] mkanat: I think the right thing to do is ask poolie [04:16] lifeless: Okay. In any case, I don't think that multi-threaded server is a good future for loggerhead (or for any Python web app). [04:16] lifeless: I think that either your 1-thread solution or Spawning is probably a good way forward. [04:16] mkanat: sounds reasonable to me; for spawning I'd really want to know we're going to be able to jump on it when it dies. [04:17] lifeless: Dies as a project, or...? [04:17] one problem with spawning is that if the parent process has any threads, fork() becomes (sadly) dangerous [04:17] mkanat: the server [04:17] lifeless: Okay. So the parent just has to be single-threaded. [04:17] mkanat: yeah, which can be hard to enfoce. [04:19] lifeless: Well, but I have complete control over the entire application, so it shouldn't be too much of a problem. [04:20] We run persistent bzr serve :) [04:23] AfC: Okay. :-) Under a high load? [04:23] mkanat: no, not really [04:24] Yeah. I think loggerhead is the only high-load multi-threaded application that interacts with bzr. === Ursinha is now known as Ursinha-zzz [04:52] * poolie reappears [04:53] lifeless: as i said to mkanat when i started, i don't think mpm vs internal fixes are either or [04:53] except in the sense that you choose one of them to work on at any particular moment [04:54] yeah [04:54] makes sense to me [04:55] having spent X amount of timing doing fixes within a single-process multithread model [04:55] perhaps we should now alternate [04:56] That makes sense. [06:12] that pyutil patch looks nice, spiv [06:12] i haven't read it closely yet [06:13] Oh good :) [06:14] I was starting to wonder if it was too much of a yak shave, but the repetition of a bug-prone idiom was really grating. [06:14] ok [06:14] spiv: thank you [06:15] i'm going to try to interactively test my launchpad dkim/gpg fixes branch [06:15] then go back to stale lock detection [06:15] ubuntu mounted (using LABEL=) my snapshot of home, not the real home [06:15] which made things a bit interesting [06:15] thus my sudden disappearance [06:15] Getting an interactive test environment running for that sounds a bit intimidating. [06:15] Heh, tricky! [06:15] mm it might be [06:16] wgrant pointed me to doc/mailbox.txt [06:16] which might be a good way to test it [06:16] we'll see [06:16] in theory i can tell it to just pull mails from a directory, or get a test to run from a canned mail [06:16] *nod* [07:07] istr there's a bzr/gnome plugin that will update a desktop flag/alert that there are/aren't branches updated? Does that tool or one like it 1. access codehost bzr+ssh; 2. on a regular schedule? or more randomised? 3. thundering herd? ie all checks at once, vs randomly spread over the given period? [07:08] Or possibly something else. But evil is happening. https://lpstats.canonical.com/graphs/CrowberryLoadAverage/20100921/20100922/ [07:08] it seems to be the same bunch of branches too; fwiw. [07:09] Wow, interesting. [07:11] is that maybe vila's bzr-gardener? [07:24] hi all [07:25] hmm, me ? [07:25] no, not you [07:25] hi vila [07:26] let see, I have ~350 branches I think, and it takes a while to query them all [07:26] wow, *something* is happening indeed :) [07:26] vila: yeah, not you :-) [07:27] regarding bzr-gardener, it's not optimized at all so far, but should *reduce* the load on the server ultimately by doing *less* queries [07:28] spm: so roughly the load has doubled right ? [07:28] vila: yeah [07:28] spm: was there an update around this point ? lp or bzr / [07:28] ? [07:29] crowberry == code.lp.net right ? [07:29] yup [07:29] and no, no code update [07:29] I think. checking... [07:30] no. not since the release. [08:06] thanks for feeding my patches up spiv [08:07] the break-lock may fail pqm, i forget [08:07] That's ok, I'm curious to see what the failures are if there are any, and also I figure it might give news_merge a chance to show if it's working. [08:08] Although maybe those merges cause a bunch of NEWS entries to appear under 2.3b1 that will need to be moved to 2.3b2... [08:08] (not so much due to news_merge as due to letting branches sit unmerged for so long) [08:09] ah it was a conflict, but not in news [08:10] but it should be good now [08:11] spiv: yeah, that's why I gave the warning to the Patch Pilot, may be you missed it ? [08:14] vila: apparently! [08:14] It's not a big deal to fix them up just after they land. [08:14] And easier than fixing them up before, thanks to the way LP reviews work :/ [08:16] yeah.. we still need to fix the root problem but until then a single patch to fix the NEWS entries wfm [08:17] An option for news_merge to force new entries to be put in the latest release seems good, except for the times when you want to change older releases (merge from 2.x -> 2.x+1, or fixing typos, etc) [08:18] spiv: I see "Simplify connect_ssh/sftp error" in the pqm queue, great, I was about to report that babune repeatedly fail in test_bad_connection_ssh so if something is still wrong after your patch we hopefully know it soon [08:19] spiv: or allow a "floating" release so that you can insert the entries either in bzr-2.2.1 or bzr-next [08:19] or bzr-dev whatever [08:19] vila: yeah, I'm still not 100% comfortable with it, but after sleeping on it I think the best way to get comfortable is to get it in trunk and battle-tested. [08:20] spiv: I've run it across all platforms with success as mentioned in the mp, it's better than the actual (and faulty) access to e.errno [08:20] vila: or provide a way to override the always-add-to-newest behaviour per landing... [08:21] Yeah, I think it's ok, I'm just still bugged by the fact that I don't understand the intent of the old code. Probably that's because the old code was wrong :) [08:21] bzr-next *is* always-add-to-newest, if you don't use it... you don't use it :) [08:22] Sure. [08:22] spiv: it could be that the old code was relying on a bug in the test code... [08:22] Heh. [08:23] the comment can be read as: "We are time dependent here, let's catch it" [08:24] or rather [08:24] it may have been inspired by a time dependent behaviour [08:33] Yeah, that's true. [08:44] poolie: I'm a bit stuck on the SRU process, bug #528041 seems to imply that I need to propose a branch (and lifeless mentioned disjoint history :-/) plus pitti replied with: "please upload" [08:44] Launchpad bug 528041 in bzr (Ubuntu Lucid) "bzr: ERROR: exceptions.AssertionError: _remember_remote_is_before((2, 1)) called, but _remember_remote_is_before((1, 6)) was called previously. (affected: 22, heat: 145)" [Undecided,Confirmed] https://launchpad.net/bugs/528041 [08:45] poolie: both of which are close to chinese to me :-( [08:45] for the former I mean that building the same kind of branch as lifeless did is [08:54] vila: ? [08:56] spiv: why not approving the patch for 2.0 as well? [08:56] lifeless: I'm lost in the dependencies between the branch you created there, the bzr stable branches and the bzr packaging branches [08:57] lifeless: oh, and I forgot the debian branches [09:00] vila: oh; sorry ;P [09:01] bonjour vila! [09:01] bialix: _0/ === spike_ is now known as spikeWRK [09:02] never seen before this acronym: aTdHvAaNnKcSe [09:02] 's not an acryonym, just a visual joke. [09:02] * bialix thinks vila had too big head today [09:02] bialix: hehe, easier to decode with the caps :) [09:02] bialix: _./ [09:02] rotfl [09:03] \o_ [09:04] \o/ ^o^ /o_ /o\ [09:04] a gull? [09:04] (it's fun to stay at the...) [09:05] poolie: and on the overall releases, it seems that many things depends on the debian branches being updated, yet, I'm still unclear about which releases debian really cares about (my best guess so far is 2.1/2.2/2.3 though I think they carry only two of them :) [09:05] vila: packages.debian.org/bzr [09:05] heya poolie [09:06] hi bialix [09:06] poolie: ha, cool, I've mailed the debian packagers for bzr but I'm still waiting for an answer, this is indeed part of it ;) [09:06] vila mind you that doesn't exactly answer the question [09:06] i guess it's 2.1, 2.2, 2.3 [09:07] amazingly 2.3b1 is already there [09:08] ha, right, jelmer did that [09:08] i wonder when natty opens, or whether it's already open [09:08] It can't open until Maverick's released. [09:08] We'd like to change that, but it's Hard. [09:09] ah i thought so [09:09] ok, i'm going to head off [09:09] jelmer: pingaling [09:20] GaryvdM: stop reading my thoughts [09:20] ???? [09:20] Hi all [09:20] GaryvdM: Naoki just committed on bug #641557 [09:20] Launchpad bug 641557 in TortoiseBZR "error while trying to run command via context menu (affected: 2, heat: 12)" [Critical,Fix committed] https://launchpad.net/bugs/641557 [09:21] GaryvdM: I was thinking about you and it's irritating to see you arriving just as this second as if you were reading my thoughts *again*. I told you to not do that anymore ! [09:22] 1. Develop mind reader. 2 Use mind reader. 3. ????? 4. Profit [09:22] *2. Use mind reader on vila [09:22] yeah, yeah, they all say that ! That's not because I'm not paranoid that they aren't all after me ! [09:23] GaryvdM: more seriously, I was updating http://wiki.bazaar.canonical.com/Releases/2.2.1, you're currently building the windows installers right ? [09:24] I'm paranoid. But am I paranoid ENOUGH? [09:24] fullermd: never [09:24] That's just what I expected you to say! [09:24] vila: Yes - Sorry - I ment to do that, but got side tracked. [09:24] fullermd: did you notice those black helicopters *behind* you ? [09:24] fullermd: no need to turn around, they do that too so they are *still* behind you [09:25] GaryvdM: no need to be sorry ! [09:25] * fullermd nods wildly at vila. [09:25] lol [09:25] 's why I lay on my back. Then I only have to worry about the black subterrines. [09:26] Oh, I'm fine on this side... mines you know [09:27] Who build the OSX installers ? Gordon ? I can't remember his IRC nick. Someone ? [09:38] bialix: only because I didn't see it in the queue, it turns out it was the very last thing on the +activereviews page because someone else had already voted Approve [09:38] bialix: I just changed the status to Approved for you === bialix_ is now known as bialix [09:49] what exactly is stored in a versionedfile/text-object? each line with: text of that line, author, date? or just text + revid? [09:50] for current format if that changed over time [10:00] vila: Gordon is doxxxx (not sure about qty of Xs) [10:00] hey [10:00] bialix: ha right, of course, thanks ! [10:00] http://doc.bazaar.canonical.com/developers/integration.html comes from where? [10:00] I've got a request for some extra examples for that page [10:00] thumper: lp:bzr-alldocs [10:01] thumper, sorry [10:01] in the source tree you mean ? [10:01] I'd really like examples for getting a diff for a revision [10:01] thumper: it's inside bzr.dev/doc/developers [10:01] and a diff for a revision for a particular file [10:01] also, how do I get a revision id from a revno? [10:01] for a branch? [10:03] Branch.dotted_revno_to_revision_id ? [10:04] thumper: could be costly [10:04] vila: I'm only dealing with mainline revisions [10:04] If it's non-dotted, there's another method, which is oodles cheaper. [10:04] does that make it easier? [10:05] thumper: Branch.get_rev_id [10:06] thumper: in the worst case the whole ancestry graph is loaded :-/ [10:06] What's the quickest way (when no one at the server end is awake) to determine the version of an svn server? I just read the bit about metadata pumped into svn by bzr when the upstream svn server is 1.4. === bigjools is now known as bigjools-afk [10:07] dlee: programaitcally? [10:07] it's in the footer of the webdav repo browser usually if thats good enough [10:08] Ah, embarrassing - and yeah good enough. I'd looked in lots of places but not with a browser to the svn path [10:10] vila: what is the history optional param to the get_rev_id method? [10:11] thumper: no idea :) Let me see [10:14] it'd be useful if you added an example of how to turn the input from the revision option into a revision_id :) [10:14] or does it do that itself? I didn't check [10:15] thumper: shame it's not documented nor used a lot :-/ It seems to be a simple list with the revids int it indexed by revno -1 [10:15] s/int/in/ [10:16] thumper: but almost no callers use it [10:16] heh [10:16] thumper: do you intend to use it a lot for the same branch or is it just one call here and there ? [10:17] I intend to be able to walk back through history in jumps of say 20 revisions [10:17] for display on a web page [10:18] I could just have the revision history cached actually [10:18] as webapp overhead [10:18] it wouldn't be too bad [10:18] * thumper thinks of loggerhead [10:18] perhaps not so much of a good idea [10:18] lets skip caches I think [10:19] vila: primarily for page or site history for wikkid [10:20] how do you get commit history for a single file? [10:21] thumper: the clean way or the dirty way ? :D [10:21] actually, I might put down the laptop and watch Chuck :) [10:21] vila: clean please [10:21] efficient [10:21] thumper: hehe, the dirty is efficient ;) [10:22] but, well, wikkid context, so focus on single files, no dir contents involved and you always start with a known path/file-id [10:22] thumper: correct ? [10:22] yep [10:23] seriously though, I'm walking away ;0 [10:23] laptop is back in the office now [10:23] and the warmth is in the lounge [10:23] caio [10:23] thumper: ok, np, I've starting playing around with wikkid [10:23] cool [10:23] http://wikkid.biz/ ? [10:23] thumper: more as a user but with some opinoins :) [10:23] Glenjamin: lp:wikkid [10:24] oh wow, that sounds clever [10:24] Glenjamin: yeah, thumper is :) [10:26] thumper: I've been refactoring qlog's internals. One of the things I have done is separate the cache form the state, so that it can be used more easily in a web environment (I had loggerhead in mind). [10:27] thumper: One of the things it can do is show a history view, filtered by file id. [10:27] or file ids [10:27] thumper: so it my be use full to you. [10:28] My refactored code is here: lp:~garyvdm/qbzr/log_refactor/ [10:29] thumper: It's maybe to soon to use for your purposes, but please keep it in mind. [10:30] thumper: If you take a look, look at lib/loggraphprovider.py [10:33] thumper: You would cache a LogGraphProvider for the branch, and a FileIdFilter per file, and then create a GraphProviderFilterState per request. [10:41] hey GaryvdM [10:41] Hi bialix. [10:41] should I do the release of 0.19.2 tonight? [10:42] I don't mind doing it. [10:42] hello, what does this mean? bzr: ERROR: Connection error: while sending POST /bazaar/: [Errno 0] Error [10:42] GaryvdM: please, land your latest patch [10:43] ok [10:44] xrmx: it depends on your URL [10:44] bialix, bzr branch lp:wikipbx , works in my machine, does not work on a chroot [10:44] hmm [10:44] bialix, chroot can ping outside world [10:45] maybe because you need to run bzr lp-login on chroot? [10:45] bialix: Done [10:45] shouldn't do to branch [10:45] GaryvdM: thanks [10:45] xrmx: smells like a bug [10:46] bialix, my chroot is base debian squeeze plus apt-get install git bzr [10:46] bialix, bzr 2.1.2 [10:47] can you post the ~/bzr.log ? [10:47] setting bzr lp-login would require copying you ssh key to the chroot [10:48] Ah - I think I know what is wrong... [10:48] Glenjamin, http://pastebin.com/8QShrp9w [10:48] * GaryvdM finds bug [10:49] xrmx: Maybe try bzr branch http://bazaar.launchpad.net/~wikipbx-dev/wikipbx/trunk [10:50] GaryvdM, that works fine thanks [10:51] what exactly is stored in a versionedfile/text-object? each line with: text of that line, author, date? or just text + revid? (latest format version if that matters) [10:53] xrmx: I think your bug has a similar cause to bug 634466 [10:53] Launchpad bug 634466 in Launchpad Bazaar Integration "bzr branch lp:subvertpy fails as it gets a private branch url. (affected: 1, heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/634466 [10:54] xrmx: Please log a bug: https://bugs.edge.launchpad.net/launchpad-code/+filebug [10:56] knittl: Disclaimer: I'm not fimilar with the internals of versionedfile. What I'm saying is based on my knowledge of the api. [10:56] GaryvdM: that's ok. versionedfile is just an API [10:56] and it's more than nothing :D [10:56] knittl: I think that it only stores the text. [10:57] The revid is in the reference to the versionedfile object. [10:57] how can the text be mapped to revisions? [10:58]