We already have the ability to do diffs between revisions of the diff (just click the boxes in "Changes between rX and: ...") We store only the diffs to keep the size of the database smaller, and rely on heavy caching to prevent fetching from the SCM too often.
-David On Thu, May 21, 2009 at 5:23 PM, Alexey Morozov <morozov...@ngs.ru> wrote: > > Hi! > > On Thursday 21 May 2009 16:17:12 David Trowbridge wrote: >> At VMware, we have a couple thousand engineers working on a single >> server. Granted, I think it's a VM >> with 4GB of RAM and multiple vcpus, but it's still a single server. >> >> We've been addressing performance recently, and while it's pretty >> good, there's still more to do. MySQL >> isn't a big bottleneck--most of it is computing the diffs to display. >> I don't think you'll have any trouble >> getting 200 people up and running. > > Regarding the method to handle diffs. > > How do you think wouldn't it be faster if ReviewBoard internal data model was > slightly different? Instead of keeping patches it might keep entire source > and target files. In this case diffviewer job looks less demanding (now it > anyway deals with both files, and target file is produced by patch, which > isn't that fast, I guess). Also such data-model allows to see difference > between any versions of a changed file, not only between its "source" > and "target" states. This might be usefull to quickly see if a developer > actually put requested changes to a review being discussed. > > Best regards, > Alexey Morozov > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "reviewboard" group. To post to this group, send email to reviewboard@googlegroups.com To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~----------~----~----~----~------~----~------~--~---
