Whee, I get to be a wet blanket! We don't even have any request-writable storage at the moment. SQLite is horrible with write concurrency (and is on an NFS share, to make matters worse), and straight NFS-based writing (sans SQL) would have to be guarded with locks. Even if we solved those problems, complete rendered pages are currently stored. That means any saved "permalinked" page would be stuck with its original set of menus and other markup despite future changes to the UI, leading it to become more inconsistent (and quite possibly nonfunctional as JS's assumptions about DOM structure are broken) over time.
Thus, I think the real solution is to hold off until DXR stops plunking 25GB of rendered HTML on NFS and starts rendering it dynamically. That's slated for sometime after next quarter's transition to an Elasticsearch backend, as it depends technically on that. Once we have request-time rendering of indexed content, it will be a lot more straightforward to fetch and render arbitrary revs out of version control the same way. We just won't have analysis—only syntax coloring—since we won't have time to build the whole project during the request. ;-) MXR's ability to half-ass an analysis at request time is a deeper question with no clear answer, short of implementing an entire second analysis engine that operates more heuristically. DXR's strength right now is its exactness. Ideas are most welcome. Erik On Mar 18, 2014, at 22:20 , smaug <sm...@welho.com> wrote: > mxr can do specific revision + multiline. > Something like > http://mxr.mozilla.org/mozilla-central/source/docshell/base/nsDocShell.h?rev=492ce94e6528&mark=94,96,98,100-113,120-134#90 > > You get the revision number from the bottom of the page. (That UI isn't too > great.) _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
