[00:00] mbt: I'm busy for a fix for that bug (https://code.launchpad.net/~garyvdm/bzr/bug492116-ls-file/+merge/45679) [00:01] Oh! [00:01] I'll mark my bug a dup [00:01] *dupe [00:02] GaryvdM: hawk eyes you have :) [00:02] GaryvdM, thanks! [00:03] spiv: has it landed yet? [00:03] GaryvdM: the issue is that there is some weird interaction with hudson, so for the time being I keep them blacklisted [00:03] GaryvdM: I know "some" people are still running them so I'm not worried about regression there :) [00:03] GaryvdM: especially since they cover a developer feature :D [00:03] zyga, am breaking for dinner; will be back in a bit. if you need to get a hold of me my email and jabber info is on my LP profile [00:04] GaryvdM: oh, and by the way, these tests are disabled for *all* platforms, not only windows [00:04] vila: oh! [00:05] vila: I also had problems with them in the past. So I'm also running with ""-x TestBreakin" [00:05] GaryvdM: you shouldn't ! [00:05] :-D [00:06] I rely on *you* :) [00:06] ok [00:06] * GaryvdM restarts tests. [00:08] vila: btw - this is on windows, with the standalone install. [00:11] vila: I [00:11] vila: It hangs on "blackbox.test_breakin.TestBreakin.test_breakin_harderbreakin_harder" [00:12] GaryvdM: hmm :-/ [00:12] GaryvdM: file a bug or is there one already for that ? [00:12] GaryvdM: and ping jam :) [00:14] vila: ok [00:14] I'll do that tomorrow. Good night. === GaryvdM is now known as GaryvdM_away [00:18] mbt: okay [00:18] mbt: I got first _very_ rough version that talks with remote daemon [00:19] mbt: I only route the info() request this way [00:19] but it works [01:22] zyga, I am back. [01:25] What is the "submit branch" (in particular in comparison to the "parent" branch)? [01:25] mbt: great [01:25] mbt: I'll commit and push my stuf [01:25] mbt: it's not much [01:25] exarkun, It is the branch used for the "bzr send" command [01:26] weuoook [01:26] exarkun, you can specify the parent branch as :parent [01:26] exarkun, e.g., bzr send :parent [01:27] mbt: pushed [01:27] mbt: check it out [01:27] mbt: it's nice, I'm working on more [01:28] mbt: okay thanks [01:28] zyga, sure thing, one second [01:28] zyga, what's the link to the branch? [01:29] oh nvm, I can pull can't I. [01:29] lp:~zkrynicki/+junk/redmine-bzr [01:29] :-) [01:29] right [01:29] I think submit is also used as a default for merge. [01:31] mbt: the adapter hardcodes the location of the rpc server [01:31] zyga, looking now, [01:32] mbt: eventually you will be able to talk to the server entirely so the url/root url will no longer be meaningful and the branch server can be all that you specify [01:32] mbt: with my branch you can also see all the merges [01:32] mbt: but there are some bugs so if you find something broken leave me a note [01:32] mbt: if you compare my adapter to yours you'll see I removed some if's === dOxxx is now known as dOxxx_away [01:34] zyga, what's the change to config/environment.rb for? [01:34] uh [01:34] random junk, sorry [01:34] it's 2AM [01:35] lol okiedokey just making sure 'cuz I was all like "interrobang" [01:35] uncomited and pushed again [01:36] with --overwrite [01:38] Ah, I see how this works [01:38] it's just a start, but we can manage everything this way [01:38] the server has to be moved to initialize [01:39] but I'm already dying here, I'll hit the bed soon [01:39] What's going to manage the lifecycle for the bridge process? Or can Redmine be setup to start it up when it's persistent Rails process is started? [01:39] mbt: it's a separate topic, IMHO it can be done in several ways that will make it not a problem in practice [01:39] mbt: such as xml-rpc hosted inside apache [01:39] mbt: or just plain deployed as a separate service alongside [01:40] mbt: redmine does not need to care about this, all you give it is xmlrpc url [01:40] zyga, well, it should be able to, lest people have to do extra work when setting up for Bazaar repositories anyway [01:41] But yes, later [01:41] mbt: you don't have to setup lp.net to use lp.net url with redmine [01:41] it think it's out of scope [01:41] I'm just thinking in terms of expectations. All other SCMs work out of the box with no additional effort, so this should, too. [01:42] well that's true [01:42] mbt: we might setup something that will work like that [01:42] mbt: one thing I would look at is performance [01:42] mbt: if it's faster than everyone else [01:42] that's a plus :-) [01:43] zyga, True. It does look like, though, the way this XML-RPC thing works, it'd be entirely possible to choose a front-end (e.g., also support command line invocation) [01:43] right [01:43] ? [01:43] mbt: I only worry that setting up stuff like that is flaky [01:44] mbt: stuff like the helper dying [01:44] No more flakey than shelling out 10 times per page view to determine if the current revision is the latest one [01:44] etc [01:44] lol [01:44] it's part of the system services to oversee this [01:44] putting it inside redmine will only be more broken [01:44] right but this is about fixing things [01:44] personally [01:44] apache + xmlrpc server is probably most resiliant method [01:45] but we'll need to check how all those read locks behave [01:45] I'm really curious how lp.net does this [01:45] Hrm. [01:45] running loggerhead _AND_ allowing you to push all the time [01:45] I'm sure that "buy-in" will be better if it can be done as an either/or [01:45] unless they mirror the branch you push to scratch space to run loggerhead from [01:45] zyga, probably doesn't hold the locks any longer than necessary [01:45] or that. [01:46] mbt: I never saw it hold any locks and loggerhead can take a while to run [01:46] mbt: setting up redmine is ~10 minutes if you follow the docs [01:46] mbt: I'd add +2 minutes to setup the service for bzr [01:46] but in a way that will recover, not just running it like that from the comand line [01:46] that can be done after it works [01:46] Well, one could use dæmontools or Upstart [01:47] mbt: yeah there are lots of options [01:47] But not every server is going to have the ability to do that either [01:47] apache is the logical choice if you already run it [01:47] to run what? [01:47] why not? managed crippled hosting with rails? [01:47] A server where you can deploy rails apps, might not permit ssh access or the ability to run any (other) persistent processes [01:49] mbt: perhaps, but personally I dont find this that important, if you already host your code somewhere else you might as well host it using public services, setting up a django app on google app engine that will do this is trivial and will not require anything fancy [01:49] (perhaps apart making sure that the app can actually talk to the repository) [01:49] mbt: so for the moment, let's fix the adapter, figure out how to make people deoploy it later [01:49] Indeed. [01:49] :) [01:50] mbt: another thing, it can run on _separate_ sever [01:50] Well, go ahead and head to bed, and I'll work on this for a while, maybe see if I can get feature-parity tonight [01:50] zyga, Indeed [01:50] mbt: usually you do have bzr+ssh to get the code in the first place [01:50] mbt: thanks, I'll talk to you tomorrow [01:50] mbt: btw, I'm +1GMT, you? [01:50] zyga, sure thing. Thanks! [01:50] zyga, -0500 [01:51] okay, see you tomorrow [01:51] So noon there is several hours before I wake up here :) [01:51] zyga, yep, night === frakturfreak1 is now known as frakturfreak === dOxxx1 is now known as dOxxx === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === zyga is now known as zyga-efika [10:45] I am on revision 10. I bzr rm'd a file on revision 4. How do I get that file back? [10:45] Thanks :) [10:45] bzr cat -r3 xxx > xxxx [10:45] bob2: thanks, will try now [10:47] bob2: great, never knew about bzr cat. brilliant. [10:47] you'll not get any blame like that, no? [10:47] note: bzr will have no idea what you did [10:47] mgz: right [10:47] true [10:47] You can revert the file back to r3. [10:47] `bzr merge -r4..3 xxx` any better? [10:47] That way, bzr will know it's the same file. [10:48] mgz: oh, didn't think of that [10:48] i've tried that too, bzr revert -r3 robots.txt - didnt do anything [10:48] I'm not certain it's any better, but might be. [10:49] Works for me. [10:49] Just tested it. [10:49] jelmer, Do you know the evolution codebase well, or do you just keep a PPA of it? === oubiwann is now known as oubiwann_ === oubiwann_ is now known as oubiwann [13:21] bzr branch lp:ubuntu/$suite/$package rules! === oubiwann is now known as oubiwann_ [13:57] I want the contents a particular revision of a bzr branch (I'm packaging, I don't care about history whatsoever). Currently I'm doing 'bzr co -r ... '. This is slow. Is there a better way? [13:57] In fact, can I use 'bzr export' on the remote branch? [14:03] You probably can, yes. [14:06] Hmm, that causes problems. [14:06] In that previously I had a local copy that I could use for looking up revnos (for example). [14:06] Whereas now I'm using the remote one, which could change between my export and my revno lookup. [14:07] Is there any way I can get a lightweight checkout of a particular revision? [14:09] You could use a revid, which isn't going to change. [14:09] Odd_Bloke, What about export [14:09] bzr export -r URL [14:09] oops [14:09] bzr export -r revid URL [14:10] No checkout, no baggage, just the files [14:10] Oops, didn't read all the scrollback [14:10] awilkins: :) [14:11] Added complication: I'm exporting by tag but need to look up the revision. [14:13] Ah, and 'bzr revno' won't let me specify a revision. [14:13] Odd_Bloke, You can use revno or revision-info with the --tree argument on a lightweight checkout to get the revision of the current tree [14:14] (knew it was supported because qlog does it) [14:14] awilkins: But I don't think I can create a lightweight checkout of anything but the head of a branch. [14:15] Odd_Bloke, So you can do a checkout --lightweight -r tag:WIBBLE [14:15] Odd_Bloke, Just performed a lw checkout of a 2 revision branch at r1 [14:15] bzr revno --tree # returns 1 as expected [14:18] awilkins: Victory! Thanks. :) === gthorslund_ is now known as gthorslund === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === oubiwann_ is now known as oubiwann [15:57] Yikes. This morning, I thought, "I'll just see if bug 705279 is reproducible" [15:57] Launchpad bug 705279 in bzr (Ubuntu) "bzr crashed, when pulling from a bzr mirror of an svn repo, with BzrCheckError in _commit_write_group()" [Undecided,New] https://launchpad.net/bugs/705279 [15:58] It's been running for hours, is half way through, and has transferred 3.3GB === beuno is now known as beuno-lunch [16:19] maxb, Is the vcs import of the chromium sources an old-style or new style one, I wonder [16:19] maxb, The newer ones use bzr-svn, the older ones use some other thing that isn't interoperable with it [16:20] It's the new kind [16:20] cscvs is hellspawn [16:21] I suppose I might have guessed that 'coz Jelmer created it... === beuno-lunch is now known as beuno [17:47] awilkins: hi [17:47] awilkins: I know the evolution-mapi source code a bit, not familiar with the core === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [17:49] if I do 'bzr commit -x debian' .. the debian dir should be totally ignored right? [17:50] SpamapS, yes [17:50] hrm.. not happening. :( [17:50] actually... [17:50] SpamapS, you are seeing it in the diff if you "bzr diff -c -1" after the commit? [17:50] it shows in the modified list if I specify no message.. [17:50] but it is not actually committed [17:50] yeah [17:50] DOH [17:51] * SpamapS looks for the surely already open bug report to +1 [17:51] jelmer, Ah, it's more the evolution-exchange stuff I was interested in ; our Exchange server is trapped behind one of these cookie redirectors so I was wondering how hard it would be to implement the same sort of solution described here ; http://blogs.interknowlogy.com/timmccarthy/archive/2006/08/05/3659.aspx [17:51] bug 552805 [17:51] Launchpad bug 552805 in Bazaar "Commit message template does not exclude files" [Medium,Confirmed] https://launchpad.net/bugs/552805 [17:51] james_w`: I'm not sure what to make of the fact that you know the bug # by heart ;) [17:52] SpamapS, only google knows that [18:20] possibly this should not be an internal error: http://buildbot.twistedmatrix.com/builders/debian64-py2.4-select/builds/894/steps/bzr/logs/stdio [18:22] glyph: I agree. jelmer? [18:23] glyph: jelmer says that may already be fixed in current bzr-svn [18:23] glyph: inspection of the code suggests yes [18:25] glyph: interactive testing however suggests no! [18:25] glyph: investigations continue [18:26] (Apparently this is not ERR_UNKNOWN_HOSTNAME?) [18:39] spiv: I don't know man, I don't even work here [18:43] Dumb question, I can't find this in the docs it seems: given a branch and a file_id, how do I get the last revision that modified the file_id? [19:04] jelmer: please can I ask you do advise me on bug 704840 [19:04] Launchpad bug 704840 in QBzr "qlog crashes on svn working copy" [High,Confirmed] https://launchpad.net/bugs/704840 [19:04] I posted a question in the bug. [19:08] GaryvdM: thanks for the installers ! [19:09] vila: It's a pleasure :-) [19:12] vila: I got the test suit to finish for the first time (with the standalone installer.) I had to exclude a bunch of https that were causing the test suit to fail. [19:12] s/fail/hang/ [19:12] GaryvdM: fail [19:13] GaryvdM: grr, file a bug with as much relevant -s xxx you can think of and I'll try to give you more instrucitions [19:13] to better localize the problem [19:14] Ok will do. I'm going to slowly work at. === Ursinha is now known as Ursinha-afk [19:43] GaryvdM: by the way, 2.2.3 in the pipe... :) [19:44] vila: Ok [19:45] GaryvdM: hmm [19:45] GaryvdM: I think we should fix the bzr-svn config [19:46] GaryvdM: but I'm also a bit surprised by the actual implementation in bzr.dev [19:46] jelmer: ok [19:49] I battling to grok the "increasing the python requirement " thread in ml. Where any decisions made? [19:50] I'm not sure, I had the same problem :-) [19:50] GaryvdM: "stick with 2.4 for now" is the short answer [19:51] spiv: Thanks [19:51] GaryvdM: with some interest in playing with 2to3 etc sometime soon to see how hard it would be to run on 3.x [19:55] how do I eliminate a specific revision? [19:58] * mbt 's ears perk up [19:59] Python 3.x? Yes? Yes? :) [20:00] mbt: I wouldn't hold your breath... [20:01] lol, yeah, that seems to be the general consensus in most major python systems [20:03] spiv, You wouldn't know how to answer my ? from earlier, would ya? I'm still stuck; I seem to be barking up all the wrong trees [20:04] ha, ha, that was an awful pun [20:05] mythril: if there are no revisions after the revision you want to eliminate, then you can do a bzr uncommit === Ursinha-afk is now known as Ursinha [20:06] mythril, Do you need to eliminate it from the history, or would reverting it be sufficient? [20:06] mythril: if there are revisions after, you could do a reverse cherry pick to revert the changes made by that revision, but the revision would still be in the history.. [20:08] Should be possible also, in theory, to make a new branch, then on the old one, uncommit repeatedly to back way up, and then merge from the new branch as a cherry pick. Then only the dead revision has to be pruned, right? [20:16] mbt: this is also something that bzr-rewrite was developed to help with [20:16] I don't know the specific invocations, though [20:16] (something like "bzr rebase") [20:16] but there have been complaints that rebase doesn't work very well with a single branch, etc. [20:24] mbt: re you question about getting the revision that last modified a file [20:24] If you get the inventory item for the file, you can call item.revision to get the revid. [20:25] You will then need to get a revno for the revid. [20:27] I _think_ I found a way, using iter_entries_by_dir from RevisionTree [20:27] I'm not sure how you are iterating the files, and hence what is the easiest for you to get the inventory item [20:27] That will do. [20:28] mbt: shout if you need help to go from a revid to a revno [20:29] GaryvdM, That I think I have; but whether or not the way I am doing things is going to be efficient is yet to be determined. [20:29] mbt: is this for a web server? [20:30] Yeah, I'm workign on getting Redmine (a Ruby on Rails application) to try to support shared bzr repositories. [20:31] But the way that the bzr command line tool works, and the way that Redmine works, well, they don't have the same conceptual model of things. [20:32] Unless I am missing something in bzr or bzrlib, without a branch context a lot of operations are impossible. But Redmine does not give you the branch context if you tell it that the revision system supports branches; instead it treats branches as a reference to a revision number (as if it were a tag in reality), and path information won't include the branch in that instance. [20:33] So instead, I'm trying to use the approach that it uses for subversion, which is to pass the repository as the URL; the URL may or may not be a branch, and if it is not a standalone branch, then the branch will have to be found from the relative path information [20:33] That seems to be working, but then I am left with breaking apart the branch information to find the relative path for the directory being browsed [20:34] And the odd thing is that since that comes from the RevisionTree, which comes from the repository, I can get a whole tree, but then I have to get into the branch context again to map the revision IDs to branch-local revision numbers. [20:34] What I am trying to figure out now is the most direct way of finding a path in the revision tree [20:36] mbt: Ah - the api is like that, because the calculation of revision numbers is dependent on knowing branch tip [20:36] I get the why, but I don't understand why Redmine doesn't pass (branch, rel_path) to the VCS [20:37] That would make live a lot easier, and would make the bridge between bzr and Redmine a lot less ugy [20:37] *ugly [20:37] I see [20:37] if you can guess the branch tip, and are willing to go down a api level, you could calculate the revnumbers with out a branch ref [20:37] Only other thing is: can I get a path without kicking off the generator? Something like revisiontree.get_file_inventory(file_id) some how or another? [20:38] Oh? [20:39] (Or for that matter, just get the inventory for the root directory of a working tree, since the inventory apparently has references to all of its children) [20:39] Yes [20:42] I see get_root_id in revisiontree, but I don't see a way to get its inventory without a generator somewhere. For that matter, I'm not even sure that I'm hunting in the right place in the API [20:43] revision_tree.inventory[file_id] [20:46] Oh? [20:47] Oh, well, sheesh. [20:48] Why didn't I see that like three hours ago lol [20:48] I'm not sure if that is abusing the api a bit. Maybe one of the core devs can comment on that. [20:48] I don't know but it eliminates a function or two from my own code [20:48] so that isn't bad [20:57] mbt: hi [20:57] mbt: I'm still busy today but I looked at your changes [20:57] mbt: I'll try to rewrite the single-branch model first [20:57] mbt: and see how that works [20:57] mbt: but it seems this will work [20:58] zyga-efika, I am looking at single branch ATM but I think it will transparently work for both. [20:59] I can commit my WIP in a sec [20:59] I have a very unhappy Entries list lol [20:59] unhappy? [20:59] It loads without crashing, but with empty fields [21:00] it's what I'm working on right this sec [21:00] it's up [21:01] I think it's unhappy because I have not yet taught it fetch_changesets [21:01] which is I think what I need to do next === vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | 2.2.3 is frozen, time to build the installers ! (rm vila) [21:13] mbt: I'm still occupied with my daily job, I need to finish some of the stuff in my backlog [21:13] zyga-efika, no biggie [21:14] am going to bind my branch so i don't forget to push [21:15] mbt: thanks [21:16] zyga-efika, np... thank you [21:28] abentley: I can't see 1.1 in lp:bzr-pipeline. Maybe you forgot to push? [21:29] thanks for the windows builds gary [21:30] Hi poolie. np :-) [21:31] poolie: it feels good to be able to get back in to the swing of things :-) [21:31] it's great to have you back [21:32] GaryvdM, the 1.1 release is on the stable branch, not the trunk. [21:33] abentley: oh - ok [22:04] mkanat: hi [22:04] Hey lifeless. [22:05] I was talking to poolie [22:05] about loggerhead & branches and launchpad [22:05] uhm [22:05] so you know that we've reorged the Launchpad team, right ? [22:05] lifeless: Don't know anything about it, no. [22:05] ah [22:06] so http://blog.launchpad.net/general/changing-how-we-track-launchpads-bugs-questions-and-blueprints references a mail from me [22:06] lifeless: Okay. But that wouldn't apply to loggerhead, since it's a separate product that's used elsewhere in addition to being used by LP. [22:07] (Much like bzr itself wouldn't become part of launchpad.) [22:07] thats true [22:07] what is concretely means is that we're less siloed [22:08] so we are more likely to fix things that are important rather than things that are important in one area [22:08] lifeless: Although I'd think that it will also mean that your design will become more haphazard in the individual pieces, if the same people aren't always working on them. But that's more of a side note. [22:08] Perhaps though the overall design will become more cohesive. Hard to say. [22:09] one way to find out :) [22:09] also its kindof my job, and jml's job to keep the technical and user stories cohesive [22:09] lifeless: Sure, I just would be concerned that this will shift *all* design work onto you. [22:10] Instead of allowing you to have sub-designers for the individual pieces. [22:10] mkanat: nah, I chase after rather than being a bottleneck [22:10] I like being able to sleep [22:10] lifeless: Haha. :-) [22:10] anyhow [22:11] so - I'm worried that with the separate trunk + for-lp branch that we'll end up diverging, if trunk stays unsuitable for lp for extended periods [22:11] lifeless: Oh, that is a temporary situation. [22:11] and AIUI you may be spending less (no?) time on loggerhead [22:12] what are your medium term plans vis-a-vis loggerhead? [22:12] lifeless: Whether or not I'll still be working on loggerhead depends on administrative details at Canonical, so it's hard to say. [22:12] lifeless: The only thing I'll be able to complete in the time that Canonical has currently allotted is bug 567729. [22:12] Launchpad bug 567729 in loggerhead "loggerhead could mark all pages cacheable" [Medium,Confirmed] https://launchpad.net/bugs/567729 [22:13] mkanat: will this leave trunk unsuitable for lp ? [22:13] or is it currently suitable? [22:13] lifeless: It will leave trunk unsuitable. I had a plan to make trunk suitable for LP, but it was not approved. [22:14] lifeless: The disapproval was not technical, it had to do with contracting. [22:14] ok, I'll talk with poolie and flacoste about that [22:14] Hi jam. [22:14] how much work has landed since the point it became unsuitable? [22:15] lifeless: Well, I can't be sure that history_db itself is unsuitable. [22:15] lifeless: But /raw/ is definitely not suitable. [22:15] lifeless: Although we could just hack out /raw/ easily, for LP. [22:15] s/unsuitable/suitable/ [22:15] jam: I'm running into a bzr bug when building the win installer. The bzr on the ec2 instance is quite old. [22:15] poolie: btw, that all pages cachable thing isn't useful for lp [22:16] oh, because? [22:16] poolie: we can just tell squid to do that in ~2 minutes [22:16] ah, true [22:16] jam: Admin is needed to install a new version. Please could you do that for me. [22:16] lifeless: BTW, the CSS for loggerhead on LP seems to be wrong. [22:17] lifeless: This page, for example, does not have the right CSS: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/annotate/head:/.bzrignore [22:17] the raw controller has a knob overriding it though? [22:18] lifeless: It doesn't, but it would just involve commenting out a few lines. [22:18] ok [22:18] lifeless: The only think LP needs for it to work properly is the token thing, because of the private branches. [22:19] lifeless: I'd be totally thrilled to do the work to make trunk stable and on LP though. [22:20] :) [22:20] jam, GaryvdM, i'd like to sometime migrate the windows vm to use an ebs-based root partition [22:20] then it'll be easier to save the state [22:21] lifeless, will you comment on that squid bug or shall i? [22:23] I will [22:23] poolie: I'm only using the ec2 instance for 2.2 builds. For 2.3, I'm hoping I'll be able to get a 64 bit build done, so I'm using a local 64bit vm. [22:24] ah, ok [22:27] poolie: having my own local vm allows me freedom to changes things, but I guess it's not good if I need to hand over to someone else. [22:28] lifeless, jam: Is there some plan for how storing and updating history_db would work for LP? [22:29] mkanat: hand-wavingly every project would get its own sqlite db file [22:29] which gets updated on demand [22:29] and we would pre-seed projects like emacs [22:29] jam: Okay. Does history_db do incremental updates now? [22:29] always has [22:30] jam: Okay, cool. I thought so, just wanted to check. [22:30] just that the *first* update is faster if you do it manually [22:30] * mkanat nods. [22:30] plus, it means that someone hitting the website isn't the one waiting for it to complete [22:30] Yeah, for sure. [22:31] In an ideal world we'd update it asynchronously every time somebody changed the tip. [22:31] mkanat: it actually wouldn't be a lot of overhead from that, at least my timings showed it to be quite feasible to run it as a post-commit hook in bzr [22:31] jam: That'd be great if we could do that. Would require instrumentation and changes on codehosting, of course. [22:32] at least once it has the first 100k revisions completed :) [22:32] Right. :-) [22:32] mkanat: yeah, some sort of job-task that triggers when a branch is updated [22:32] * mkanat nods. [22:32] we already have the branch scanner which does similar work [22:33] and we've been talking a bit about changing some of the postgres tables to use the history-db-like layout [22:33] since BranchRevision currently is something like 0.5Billion rows [22:33] Wow. [22:34] anyway, when we poke at that, loggerhead could just use the production tables (possibly via an intermediate db, rather than the actual live one, etc) [22:34] abentley: didn't you write up a LEP on this? [22:35] Right. That'd be even simpler if we had history_db use an ORM. [22:36] jam, not quite a LEP, but: https://dev.launchpad.net/Code/BranchRevisions [22:36] abentley: thanks. I wanted to point mkanat at the idea that we were looking at that sort of thing. [22:36] mkanat: well, it is pretty generic sql, using python dbapi2 [22:36] so you could do it to pretty much any SQL backend [22:36] jam: True. [22:37] some of the create syntax is sqlite specific [22:37] abentley: I wonder about the "use loggerhead" proposal, there. It's possible we could make it fast enough. [22:37] (PRIMARY KEY AUTOINCREMENT vs using SERIAL in postgres) [22:38] mkanat, it's not a complete solution. [22:38] abentley: Okay. Because you need to JOIN that table against other things in SQL? [22:40]