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.
On Thu, May 21, 2009 at 5:23 PM, Alexey Morozov <morozov...@ngs.ru> wrote:
> 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
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to
For more options, visit this group at