On Mon, Oct 6, 2008 at 5:12 PM, Chris <[EMAIL PROTECTED]> wrote:
> I've been playing with RB the last week or so and I'm really
> impressed. The syntax highlight for diffs is awesome!
Glad you like it!
> I've added (as a comment to the end) a couple of additions to
> Hopefully they will be helpful, they are basically things I hit and
> then found in the mailing list/group.
Thanks for the FAQ entries! I'll incorporate them into the main FAQ when I
get some time to do so.
Now for the dumb questions :-)
> Is there any value in me posting a review with a patch that adds
> revision numbers to the file list in diff view? I know the revision is
> in the diff (under each file name) but with source code systems where
> each file may have a version, seeing the rev in the files changes list
> is (IMHO) handy.
I wouldn't be opposed to this, though revisions get quite large for some
systems (think Git, Mercurial, etc. which use SHA1 values for revision
information). We'd need to figure out something clever there.
> Once a review has been "set submitted", is there the concept of
> finding the change number that fixed it? The only way I can see is
> ensuring a bug tracker is used than clicking through to that. Do other
> people edit the review with the change number before "set submitted"
> or is this not something anyone has a need for?
This is highly dependent on the version control system and we'd need a hook
script that updated Review Board, along with a way to tell the hook script
which review request had the submitted diff.
Take SVN, for example. There's no standard way of passing along such
metadata and rarely do people use standard templates of any sort for SVN
commit messages. However, someone could require a certain format for
specifying the review request ID, have a hook script that then updated the
review request, and then things would work. It'd be very non-standard,
In the case of something like Perforce, companies tend to have changeset
description templates, and one could provide a field for the ID. Again,
there would need to be a hook script that handled updating the review
Another option would be to require a wrapper around svn, p4, or whatever
tool is being used which did this work.
Once that's figured out we'd need to figure out how best to update the
review request with this new information. Post-1.0, we could provide a field
indicating which revision the code was committed in, and then provide API
for scripts to set this. At the moment we don't have much of anything for
this, though, but if someone wanted to write it we'd take it, and it would
probably be fairly easy.
Last one, the emails that get sent out for review on my system end up
> having extra slash in the url after the domain:port, e.g.:
> so the url doesn't work, is anyone else seeing this or is this a
> misconfiguration on my part? I've tried setting the domain with and
> without a trailing slash (initially I set it WITH a slash, maybe this
> caused it).
I think this is due to bug 640 (
http://code.google.com/p/reviewboard/issues/detail?id=640), which I'll try
to look into tonight.
Christian Hammond - [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
For more options, visit this group at