[01:09] morning [01:51] lkoggerhead question -- Is it possible to configure it to serve on a subdiretory? [01:52] *loggerhead [01:52] Like this: [01:52] http://localhost/bzr/myproject/branch-foo [01:53] I haven't been able to move it away from this style of url http://localhost/myproject/branch-foo [01:56] abadger1999: yes, python-paste permits this [01:56] sorry pastedeploy [01:57] lifeless: Do you know the config option I'd need to change? [01:57] not offhand [01:57] uhm [01:57] are you using WSGI, serve-branches or bzr serve --http ? [01:57] * abadger1999 is also aiming to get this working with mod_wsgi... but that would come after getting it working at all. [01:58] mod_wsgi is my goal but I've experimented with both of the others. [01:58] abadger1999: I wouldn't sequence things like that; just aim directly at your goal [01:58] wsgi apps can be layer [01:58] lifeless: Alright -- mod_wsgi :-) [01:58] to do path manipulation etc in containing apps [02:02] look for PrefixMiddleware in serve-branches [02:03] abadger1999: serve-branches --prefix should do that, how are you proxying to it? [02:04] mwhudson: I'm not proxying. My last bit of trying has been based on this: http://blog.projectfondue.com/2009/11/26/loggerhead-and-mod-wsgi [02:05] abadger1999: then --prefix bzr should Just Work, i think [02:06] lifeless: There's no PrefixMiddleware in serve-branches -- the wsgi script I was using has PrefixMiddleware(app, prefix='') [02:06] Changing that to prefix='/bzr' didn't work out very well. [02:06] It made the front page correct but links to subpages had no /bzr in the url. [02:07] * abadger1999 tries serve-branches --prefix [02:10] hmm my trunk of loggerhead must be stale [02:12] mwhudson: Pretty good. It's interesting that it's serving on both /bzr and / but the links look consistent [02:12] * abadger1999 looks at code [02:12] igc: $ bzr pull [02:12] Using saved parent location: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/ [02:12] I'm using the 1.17 release right now. [02:12] No revisions to pull. [02:12] my serve-branches has prefix middleware [02:12] So it might be that things have changed since then [02:12] revno 345 [02:13] lifeless: that's not lp:loggerhead any more [02:13] mwhudson: oh [02:13] mwhudson: what is then ? [02:13] and why did it change? [02:13] lifeless: i think it's called trunk-ric [02:14] lifeless: and it was to do with upgrading to 2a [02:14] ugh [02:14] it wasn't me [02:14] I do so hate that approach [02:14] no, I know [02:14] its the approach thumper and igc advocated, IIRC [02:14] ? [02:15] lifeless: I agree it's annoying that lp:xxx can change and we don't follow the new location [02:16] I'm pretty sure there's a bug for that [02:17] I think bzr should store the url for before and after resolution [02:17] and warn the user if they change [02:17] or something [02:17] thumper: it only stores the "after resolution" info right now [02:18] igc: right [02:19] there is a bug about us storing the directory service url [02:19] however I'm complaining about the manner of upgrade where a new branch is used [02:19] lifeless: I got that [02:19] which does, I admit, interact with that bug. [02:20] however, even if we had fixed that bug, people following our docs that don't use launchpad would still have the same pain. [02:45] * igc out for a few hours === parthm_ is now known as parthm [03:05] jelmer: looks like you fixed that problem you talked about earlier? [03:18] thumper: have you looked at any rich root branches rev 1 in loggerhead before ? === parthm_ is now known as parthm [03:19] lifeless: no, but I used diff locally [03:19] lifeless: I'll check now [03:19] it could be a bug in loggerhead [03:19] I branches the branch you're complaining about [03:19] it checks clean [03:19] st -r 0..1 is clean [03:20] diff -c 1 is clean [03:20] weird [03:20] ok, not a bzr-hg bug then [03:20] the / is simply the root id being added, its normal, and IMO not a serious bug that loggerhead shows it [03:20] must be a loggerhead display bug === parthm_ is now known as parthm [04:32] mwhudson: Ah.... I vaguely remember this issue. [04:33] mwhudson: For some reason loggerhead doesn't handle URLs without a trailing "/" quite right. [04:34] mwhudson: With mod_wsgi and clicking on a directory of branches (as opposed to directly onto a branch), it goes to http://localhost/bzr/python-fedora <= no trialing slash [04:34] mwhudson: That redirects to http://localhost/python-fedora/ [04:34] abadger1999: that's quite strange [04:35] mwhudson: So something is dropping the '/bzr/' in there [04:35] abadger1999: do you have a prefixmiddleware in your wsgi stack? [04:35] mwhudson: Using serve-branches --prefix yields a slightly different issue. [04:35] mwhudson: Yeah Letme upload the script [04:36] abadger1999: what i know about mod_wsgi setup could fit quite comfortably on the back of a postage stamp, btw [04:36] http://toshio.fedorapeople.org/loggerhead.wsgi [04:37] This line probably isn't needed: os.environ['loggerhead.static.url'] = '/bzr' [04:38] mwhudson: So serve-branches.... I invoke it like this: serve-branches --prefix bzr /var/www/bzr [04:38] mwhudson: Then if I browse to http://localhost/bzr <= No trailing slash [04:38] mwhudson: There's no /bzr/ in the urls [04:41] abadger1999: i know that pastedeploy expects that the /bzr part of the path is in the script_url in the environment that it sees [04:41] abadger1999: is that something you can control from the mod_wsgi side? [04:41] maybe i mean path_info there [04:42] mwhudson: Hmm... Let me see if I can [04:42] * abadger1999 knows how to do that for TurboGears apps [04:44] jelmer: ayt? [05:03] mwhudson: Huh.... I'm a little bit stumped... I've got script_name as /bzr and path_info as /stats/changes or etc... seems to work. [05:03] abadger1999: hmm [05:03] mwhudson: But when I go to /bzr/python-fedora my instrumented wsgi script doesn't seem to get invoked at all. [05:03] well working > understanding i guess :) [05:03] ah [05:04] And that gets redirected to /python-fedora where it fails. [05:04] that sounds like an apache/mod_wsgi problem then? [05:04] So .... it seems like something is doing the redirect before the wsgi app. [05:04] I'm going to pursue that until I find out different :-) [05:24] mwhudson: Okay... this gets stranger although it's still not looking like loggerhead's fault => firefox doesn't work but wget redirects correctly. [05:25] abadger1999: sounds like you either need to go to bed or get drunk :-) [05:25] mwhudson: yeah, I'm going to second that. [05:25] Thanks for the help! [05:25] abadger1999: np [05:29] Why is this an "or"? Does nobody have the foresight to have a wet bar built in to the nightstand? [05:31] G'day, does bazaar have a way to restrict&control SSH access? [05:32] aah.. nevermind.. [05:32] Got it .. [06:42] back [06:50] igc: hi [06:50] hi mwhudson [06:51] igc: i just wanted to encourage you to just make/land changes to loggerhead trunk if you feel they are improvements [06:52] mwhudson: ok. I'm hoping to start looking at the loggerhead stuff any day now - building a Windows 2.2 installer currently [06:53] igc: ah ok [06:53] igc: loggerhead should be more fun than that :) [06:53] mwhudson: I've been reading up on WebOj and Chameleon while up at the hospital in recent days as well [06:53] mwhudson: yes :-) [06:54] i've been feeling bad for being a slack maintainer lately, and it looks like i'll be getting even less time for it [06:54] igc: i think chameleon is probably a pure win if we can keep streaming [06:54] simpletal is kinda horrible [06:54] mwhudson: np. I'll be sure to ping you asking for advice if I have any concerns about changes [06:55] igc: cool [06:55] mwhudson: yeah, I find TAL+TALES+METAL a lot less readable than jinja2 but I'll survive :-) [06:56] mwhudson: I'm curious about the stability issues as well [06:56] well if you want to rewrite all the templates... [06:56] igc: so are we all, i think [06:56] mwhudson: is there a 60 second summary of what not to touch, e.g. the threading code? [06:58] igc: i'd consider most of it fair game i guess :) [06:59] igc: the code for the url dispatch, information gathering and rendering stages is fairly separate [06:59] igc: the problems tend to be in the middle stage, unsurprisingly, so it's probably best to at least be careful there [07:00] mwhudson: by middle, you mean "info gathering"? [07:00] the "interfacig to bzrlib" bit? [07:00] igc: yes [07:02] mwhudson: ok [07:17] I'm seeing a lot of what seem to be spurious merge conflicts when I try to update a bzr branch from Bugzilla 3.4 to Bugzilla 3.6. [07:17] Perhaps there's some documentation that I haven't read? [07:39] Sorry to bug you guys again.. But we are branching a SVN tree into bzr, and would like to still be able to pull off their tree, as well as maintain history.. I assume bzr-svn is the best way of doing this? [07:39] AndrewLuecke: yes [07:39] ok.. cool.. [07:54] This is SOOOO much nicer than mercurial's and gits way of doing it [07:55] I've spent the last 4 days on this.. And this is soooo streamlined [07:55] * AndrewLuecke has become a fanboy suddenly [08:26] hi bialix [08:26] hi igc! [08:26] glad to see you [08:26] bialix: ditto [08:27] I've used explorer yesterday on colo workspace. nice work with context menu [08:27] bialix: if you get some time soon, can you try the latest bzr-windows-installers scripts? [08:28] I think we need even better support for colo [08:28] +1 from me on that [08:28] igc: perhaps on weekends only [08:28] is it ok for you? [08:28] * bialix trying to finish main work to be able attend UDS [08:29] bialix: whenever suits you is good. I'm trying to get a bzr 2.2 build with Python 2.6 (and I'm struggling) [08:29] igc: I need to make auto-generated en.po translation to be LF-only as well. is it still a problem? [08:30] bialix: no, I think the problem is elswwhere [08:30] elsewhere [08:30] python 2.6... I've tried to avoid it in my work, just because there is some struggles with py2exe [08:30] my current struggle is probably something to do with how py2exe is configured [08:31] igc: will be nice if you send me a mail closer to weekend and highlight the moments I should check/help [08:31] there's a PyQt4.uic.port_v3 on the filesystem but py2exe is falling over becuae it con't find it [08:31] there is not much configuration knobs in the py2exe [08:31] maybe env path [08:32] bialix: hmm - maybe I need to look there [08:33] bialix: i'ts very frustrating when it fails because it gives you so little to work out what's wrong :-( [08:33] igc: there is something like debug output in py2exe, at least it can generate full dependency graph for you [08:36] igc: which version of PyQt I should use? [08:36] I'm trying to build with Python 2.6.5 and PyQt 4.7.2 [08:36] bialix: ^^^ [08:36] ok, I'll grab those [08:37] bialix: thanks [08:38] bialix: with rev 108 of bzr-windows-installers, the command to run is ... [08:38] build.py installers --standalone-only [08:39] * bialix nods [08:39] * bialix has pyqt 4.7.0 as well === radoe_ is now known as radoe [09:19] thumper: https://edge.launchpad.net/codewiki [09:35] * igc dinner [09:52] lifeless: heads-up, feed-pqm doesn't prefix your commit messages with (lifeless) [09:52] vila: interesting; file a bug on hydrazine please [09:53] lifeless: I don't think so, we tend to use a rather liberal prefix there (mbp, for parthm) for example [09:53] vila: if we were to fix this, where would it get fixed? [09:54] lifeless: we never fixed pqm-submit, why should we fix feed-pqm ? :-> [09:54] because a smooth toolchain is nice to work with [09:54] so I repeat [09:54] vila: if we were to fix this, where would it get fixed? [09:55] lifeless: educate the user :) [09:55] vila: I don't understand why you don't want this automated. [09:55] lifeless: if that doesn't work, joking, let me finish :) [09:56] it that doesn't work, then either pqm or feed-pqm, probably the later, but the rules need to be defined, like, generate a prefix only if none are present and put... username there? [09:57] vila: this, file a bug [09:57] *thus* [09:57] and yes, hydrazine for now, I think === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell [14:19] suppose a remote (upstream) bound branch is at revision N, and i make a local commit, so i'm at revision N + 1, then i run bzr update, putting me back to N [14:19] is there any way to get revision N + 1 changes back? [14:22] ezod, update again (presuming you did an update to -r -2 to get to N) [14:23] no, rev N + 1 was local only [14:23] will this work: [14:23] bzr pull . --overwrite -r revid: [14:23] perhaps? [14:23] ezod, try `bzr heads` to find the revision number [14:25] `bzr heads` doesn't return anything [14:25] oh [14:25] bzr heads --dead does [14:26] ezod, find your revision and pull that [14:26] revid is email-timestamp-string [14:27] ok cool, will try [14:27] bzr pull -r revid: [14:28] awilkins: thanks, seems to have worked :) [15:01] hello, how can I fix this error ? http://pastebin.com/XVcmjnWg [15:03] c_korn, You need to upgrade the remote repository [15:03] I believe there's a button in LP for that [15:05] Or take a local branch that isn't rich-root [15:11] morning all [15:11] hey vila, I got most of the merge_sorted stuff working [15:11] some edge cases that i want to write tests for first [15:11] jam: morning jam ! [15:12] jam: good work ! [15:12] jam: so youwant to write test first ? :-P [15:12] I do that sometimes :) [15:12] seriously, when it is tricky edge case stuff, I usually do [15:12] to make sure that I'm actually exposing the code I think I ame [15:12] am [15:13] yeah, that's the idea ;-) [15:13] by the way, have a look at bug #489179 [15:13] Launchpad bug 489179 in bzr "log file -v misses some revisions" [Low,Confirmed] https://launchpad.net/bugs/489179 [15:14] jam: not for the bug itself, bug look at revno 4081.2.2 with qlog [15:15] jam: Iwas surprised by the revno numbering here, as if daggy fix could somehow violate the stability, [15:15] jam: I didn't dig but thought you may be interested [15:16] daggy shouldn't affect numbering [15:18] awilkins: ok, I think I found the button. [15:19] this is it I think: http://www.ubuntu-pics.de/bild/50919/screenshot_001_4B7Mnw.png [15:20] jam: I realize that, but just have a look [15:20] c_korn, You might want to warn the rest of the dev team :-) [15:20] awilkins: yes, I am currently doing this [15:36] vila: so what am I looking at wrt 4081.2.2 ? [15:36] vs log file -v ? [15:37] I see a lot of files merged in 4081.2.2, but that is expected, since it is all of 5112-4081 from bzr.dev being merged in one go [15:37] jam: just a sec, killed the wrong qlog seconds ago [15:38] if you are wondering about the revno, it is because they merged bzr.dev into the changelog branch, not based the changelog branch on bzr.dev [15:41] jam: ha, right, twice, I've been tricked by qlog for the other case but it's right here :-) [15:45] jam: I think my initial surprise was more about the -n0 -v revno being so far away from the revs shown by -n0, but that may just be the revno scheme after all [15:49] I don't quite understand "the -n0 -v revno" [15:49] when I do "bzr log -v -r 4081.2.2" w/ bzr.dev, I only get the one rev [15:53] Hi all [15:53] morning Lo-lan-do [15:56] jelmer: I think I found a race condition in bzr-svn the hard way :-( [15:59] Lo-lan-do: hmm? [16:00] Someone did an svn commit just as I was starting pulling a branch onto my bzr checkout [16:01] SVN did record both his revision and my series (of 21) revisions, but now I get an assertion error in my bzr checkout [16:02] File "/usr/lib/python2.5/site-packages/bzrlib/plugins/svn/branch.py", line 484, in get_rev_id/assert revmeta.get_revno(mapping) == revno [16:14] Okay, I removed revprops, uncommitted and pulled again, and now I'm fine again. [16:16] Lo-lan-do: his changes interrupted your push of a serie of revisions? [16:17] Unfortunately not. [16:17] I think his commit happened between the time bzr had read the existing revprops and the time bzr started pushing. [16:18] Lo-lan-do: but it's now interwoven with your changes? [16:18] SVN's revision history was, say, 100-101-102-103, with 101 being my coworker's commit and 102-103 being mine [16:19] But bzr log only displayed 100-102-103 [16:19] 102 had 100 as its parent bzr-wise [16:19] bug 515850 [16:19] Launchpad bug 515850 in bzr-svn "Revisions added while a commit is happening are ignored" [High,Triaged] https://launchpad.net/bugs/515850 [16:20] Sounds like exactly that, indeed :-) [16:20] Sorry for the interruption. [16:23] I know this is an odd request, but does anyone have a side-by-side technical comparison of bzr against RCS? [16:31] Lo-lan-do: np, it is an important bug to fix === deryck is now known as deryck[lunch] [16:32] * jelmer waves to jam, vila [16:32] tyarusso: hi [16:32] tyarusso: I'm not aware of one - the major difference seems to be that RCS is per-file, Bazaar versions an entire tree [16:32] hey jelmer [16:33] tyarusso: I'm not sure if that helps at all. [16:33] morning jelmer [16:33] dunno [16:33] The main thing that annoys me with RCS is that the revision files aren't "hidden", so directories get really cluttered. [16:34] jam: looks like I'll need packs for bzr-git's cache anyway [16:34] jam: group compress doesn't rely on parent information right? [16:34] jam: (for performing well, I mean) [16:35] jelmer: correct [16:35] though you need some sort of 'grouping' key [16:35] atm we use file-ids and sort them [16:35] which often works pretty well [16:35] that's fine, I'd want Git paths in that case [16:35] What happens if you do a bzr init in a directory that already has a repo going? (For instance, if you have a bunch of scripts that want to version something in /etc, and they don't know which script will run first. (not using etckeeper)) [16:35] well, you'd want filenames not paths, I would guess [16:35] or reverse paths or something [16:35] all files in a dir don't often compress as well as all files named Foo [16:36] jam: Sorry, that's what I meant [16:36] it's the same key that git uses to compress its packs [16:36] jam: Basically, I'd like to cache git Tree objects and Blob objects for symlinks === salgado is now known as salgado-lunch [17:05] Morning everyone. I am trying to push a bzr branch into an empty svn repository (for backup/collaboration purposes). However, when I run bzr push https://path/to/repo, it tells me that the branches have diverged. [17:05] Does anyone know how I can push my local branch to the remote server with bzr-svn? [17:06] This there a way to give each versioned file a description? For instance "Config file for MySuperCoolProgram". [17:07] RobOakes: your bzr branch has a different history than an empty svn branch (which has exactly one commit on it) [17:07] RobOakes: If you push to a location that doesn't exist yet things should work [17:08] For example: http://server/repo/subdir? [17:09] yeah [17:09] provided subdir doesn't exist yet [17:09] Oh, that worked great. Thanks! [17:16] is it intentional that pressing 'f' in the builtin shelve command selects "yes" for all remaining hunks? [17:16] it seems much more logical for it to select "no", since that's the default === IslandUsurper is now known as IslandUsurperAFK [17:26] hello everyone, i have a question about bzr-svn on debian [17:28] when installing on debian using apt-get i get the following: [17:29] bzr-svn: Depends: bzr (< 1.6~) but 2.0.3-1~bpo50+1 is to be installed [17:29] I suppose I *could* create a local branch for each file and name those, but that seems a little silly. [17:30] is there a repository i can add to my sources.list that would contain an updated version? [17:31] msmith: Yes, unless the repository is out-of-date too. [17:31] Don't have a link right this second, though. [17:32] msmith: Try https://launchpad.net/~bzr/+archive/ppa, or possibly https://launchpad.net/~bzr-svn/+archive/ppa or something [17:32] IIRC there is a bzr-svn ppa, but I don't remember the link. :-\ [17:35] msmith: which version of debian are you using? all versoins should have a matching bzr-svn for the bzr they have [17:35] msmith: it looks like you maybe installed bzr from somewhere else [17:35] Err, right, Debian. The PPA's out, then... [17:35] Sorry. [17:36] :) [17:36] msmith: ah, you have bzr from lenny-backports [17:36] msmith: there's no bzr-svn backported to lenny. [17:36] either install the testing/unstable version of bzr along with all its dependencies, and the matching version of bzr-svn from testing/unstable, or downgrade to the lenny version of bzr, or build your own package.. [17:36] (or ask someone else for a backport :) [17:38] ok, thanks. i'll try to follow that path and scream for help if i fall off a cliff === deryck[lunch] is now known as deryck === beuno is now known as beuno-lunch === salgado-lunch is now known as salgado === zini1 is now known as zini === IslandUsurperAFK is now known as IslandUsurper [18:25] I have 2 branches that didn't start as the same code, but I'm trying to get them to be equal. I've made both a bzr repo and added all the files. What strategy should I use to try and get them to be equal? === beuno-lunch is now known as beuno [19:34] Is there a way to get a commit history for a particular user with bzr? [19:42] http://superuser.com/questions/128540/bazaar-merge-identical-files [19:51] krisives-gearbox: you should put one branch under bzr and then, override all the files with your second branch and finally do 'bzr diff' [19:51] override> [19:51] ? [19:51] copy over [19:52] if I do that in a new area I can then push/pull those diffs into one of the original to make them all equal [19:53] when a file is first added to a branch, it receives and unique ID, if you so that in two different (unrelated) branches, the "same" file get a different ID, when your try to merge bzr then see them as different and move one away (.moved) [19:53] s/and unique/ a unique/ [19:53] meh s/so that/do that/ [19:56] krisives-gearbox: you can't start with two different histories, that's the so-called "parallel import" problem which is yet to be addressed by bzr [19:58] One issue with that strategy though [19:58] I want to end up with 2 bzr repos [20:00] nvm I think I figured it out, I'll let you know how it works [20:00] krisives-gearbox: are you sure you don't mean two branches here ? A repo for bzr is just a place to put revisions used by one or many branches [20:00] bzr init creates a repo, right? [20:01] I probably have that wrong [20:02] 'bzr init' creates a branch, a branch uses a repo, if no repo is available to be shared, 'bzr init' will create one for the branch itself, but if you intend to use several branches, you use 'bzr init-repo project' and then 'bzr init project/trunk' and 'bzr init project/feature' etc [20:03] trunk and feature will then share the repo created for project [20:03] whats the diff between merging repos and branches? or does that question not make sense? [20:04] krisives-gearbox: http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief is pretty quick to read [20:04] thanks [20:04] krisives-gearbox: you merge branches, repos come into play in the background, you rarely use them directly [20:05] ok [20:05] krisives-gearbox: 'bzr reconfigure' can also be used if you change your mind about your branches layout [20:05] I'm still thinking it out hehe [20:06] I'm integrating bzr so we can keep client sites up to date [20:06] The old system is a hacked PHP upload script garbage blah [20:07] "Whatever works" he said :) [20:08] Randomly, is there a way to tell `cp` not to copy a specific directory in a recursive? [20:10] krisives-gearbox: randomly: cp everything somewhere, delete the offending dir, cp the result ? [20:10] good idea [20:11] krisives-gearbox: 'tar' has more options, but it's also a bit harder to use it to just copy files around [20:11] You could use rsync. But, again, way complicated. [20:11] I think I'm going to do from/* to avoid getting the .bzr [20:11] cp -r from/* to/* [20:11] krisives-gearbox: Use "bzr export" to get a copy of a working tree somewhere. [20:12] usually would, but doing an "override" [20:12] krisives-gearbox: A repository is just a big bag of revisions. They can be from related branches or not. There's really not much to think about there. [21:27] jam: what's this history db thing you're working on? [21:28] jelmer: caching the dotted revno / merge sorted graph [21:29] I've posted some of the results to the list [21:29] The basic idea: a dotted revno cache can be shared between branches [21:29] as long as you store it based on the mainline revision [21:29] ah, nice [21:30] you can store it completely clustered (only new info per new mainline rev) as long as it is fast to expand [21:30] in the process [21:30] I also think I can *compute* the merge_sort graph fairly efficiently for new revisions [21:30] I think I've found solutions for everything [21:30] such that nothing is O(history) [21:31] most things are (at worst) O(history since you branched from) [21:31] some interesting other results, though [21:31] like loading the whole ancestry of mysql in 80ms or so [21:31] Wait, where would this be implemented? bzrlib? A plugin? Something Loggerhead can steal....? :> [21:31] jam: ooh, that sounds pretty nice :-) [21:32] Peng: it is currently a bzr plugin, and inspired from some of the needs of loggerhead and some other bits [21:32] <3 [21:32] also from codehosting [21:32] Granted, it would take more than this to fix Loggerhead's issues, but... :P [21:32] where I'm told there is a table that stores "what revisions are in the ancestry of this revision" for all revisions [21:33] Peng: well the root idea was that loggerhead loads the whole history graph when it often doesn't care [21:33] so how do we store it [21:33] in such a way that we can read only parts of it [21:33] and how can we make that efficient against N branches [21:33] etc [21:33] Ah. So this could be plugged into a lot of Loggerhead? [21:33] Peng: it would replace the RevisionCache, IIRC [21:34] you get to keep dotted_revnos in the api [21:34] without having them be 2s to compute per branch [21:34] get_dotted_revno() for an old revision in mysql takes 13ms [21:34] for a new revision, it si about 5-10ms [21:35] And I *think* that will scale 'out', where you ask for multiple dotted revnos in a single pass [21:35] so it shouldn't be 26ms for 2 dotted revnos, but more 14ms or s. [21:35] so [21:40] jam: what's the status on your pack collection work, is it ready to use in its current form? [21:41] not yet [21:41] I got distracted by this [21:43] We need to get you to collaborate with yourself from an alternate universe to get both done at once. :) [21:47] jam: ok [22:08] anyone there? ^^ [22:09] Possibly! [22:18] Thanks again for the help vila [22:22] jam: before you wrap for the day, could I beg a review? [22:22] jelmer: slightly obscure bzr-git kernel import failure leads to finding a sha1 problem: http://staging.launchpadlibrarian.net/42124151/mwhudson-linux-trunk.log [22:22] lifeless: of? === salgado is now known as salgado-afk [22:23] https://code.edge.launchpad.net/~lifeless/bzr/commit/+merge/22920 [22:24]