To answer your first question, no, there is no way to map the existing
comments to your new changes. This has come up a couple times over the last
couple years, so hopefully I can explain the reasoning well enough.
Comments are tied to line numbers in per-file diffs. This is the line or row
number of the side-by-side diff, a union of the two files, rather than being
the actual line of an actual file. The reason it's like this is because that
comment applies to the change being made in that side-by-side diff view. It
may be a comment about a new line that was added, a line that was removed,
or about explicit changes in a line.
What this means is that the comment is very much tied to that particular set
of changes. If a new diff is uploaded, it's certainly possible that some of
the changes and lines would match up, but in order to match them and carry
the old comments over, we'd have to:
1) Re-parse the old diff (which may involve downloading the files from the
repository again and re-patching, which can be time-consuming)
2) Build the side-by-side diff internally
3) Find the lines in the diff that the comment spans
4) Go through the new diff and try to find lines that match it (remember
that the line numbers may not match, so we actually need to look through the
diff, which is slow and may find similar but wrong lines)
Now, even doing that, we'll only get *some* of the comments, since more
often than not, there will be changes made that prevent old comments from
being carried over.
Some may argue that this is okay, and that having some comments and not
others is fine. However, this may lose context in the flow of the comments,
and that could lead to confusion.
In short, carrying over comments to a new diff isn't planned and likely will
Now, as for a summary of comments, this is really what the review request
page is for. You can see all the old comments and see the lines they pertain
to. Granted, this is on the older diff, but if you combine this with doing
an interdiff between the older diff and the newly uploaded one, you should
be able to get a good sense of what's fixed and what isn't.
There are some plans to add a basic form of defect tracking. Being able to
mark a comment as a defect that must be fixed. The developer of the patch
would see the defects and could mark each as fixed. These will *not* tie
into your bug tracker. They're just a part of the review process. We don't
have this implemented yet, and will need to sort out parts of it, but it'll
probably happen in a release or two.
Distinctions between "reviewer" and "review leader" and stuff is very much a
company-specific thing. I'd be interested in hearing what you need for this.
Keep in mind though that anything we're likely to do there will be
insufficient for other companies. Some may want specific capabilities for
certain type of people. We are looking at policy support for a future
version, which will allow admins to limit access to certain things or grant
permissions, but it's really intended for allowing a single Review Board
server to be used for different groups who may not all have permission to
see the same codebases.
I'm sorry you've had problems with the installation and that the workflow
isn't what you're used to. Review Board's workflow works just fine for many
people, but isn't guaranteed to be perfect for what you're used to.
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com
On Wed, Aug 25, 2010 at 5:51 AM, sakthi <listsak...@gmail.com> wrote:
> I finally made ReviewBoard up. I wish to know whether the following
> things are possible in Review Board,
> I tested the Review Board like this,
> Step 1: I changed a file which is already in repository and checked
> Step 2: Posted the change (diff between current and previous
> version)into ReviewBoard.
> Step 3: Reviewed, added comments, and publish it
> Step 4: Modified the code with respect to comments and checked in.
> Step 5: Posted again into the same review-request-id
> Step 6: Can see the diff between reviewed version and current version
> Now, is there a way to map the earlier comments with the code change?
> is it possible to track the comments given in a version with future
> Is it possible to see a summary of comments?
> I think it would be nice to see summary of comments and classify as a
> "bug" or "not a bug" etc
> also classify user as reviewer or review leader etc
> After a week long struggle in installation, now i feel simple XL is
> better to track the review comments than using Review Board ! or am i
> missing something?
> Want to help the Review Board project? Donate today at
> Happy user? Let us know at http://www.reviewboard.org/users/
> To unsubscribe from this group, send email to
> For more options, visit this group at
Want to help the Review Board project? Donate today at
Happy user? Let us know at http://www.reviewboard.org/users/
To unsubscribe from this group, send email to
For more options, visit this group at