On Mon, May 11, 2009 at 2:32 PM, Thilo-Alexander Ginkel <
thilo.gin...@gmail.com> wrote:

> On May 11, 9:55 pm, Christian Hammond <chip...@chipx86.com> wrote:
> > With this SCM, is the change identifier a server-stored ID that contains
> the
> > description and other information for Review Board to parse? Or is it
> more
> > like an atomic ID representing that change that gets pushed to the server
> > when committed?
> The SCM supports both committed and uncommitted changes and in both
> cases the change ID provides a means to retrieve meta-information
> about the change (such as a description, list of involved files, etc.)
> from the SCM server.
> > If the former, and if you want to support pulling that information from
> the
> > server, then we'll need a patch to make Review Board less strict about
> the
> > type of input, and move validation of the ID into the SCMTools.
> >
> > [...]
> I actually got a first version to work by declaring the repository not
> to support change sets and moving the summary / description retrieval
> into post-review where the full change id is still available.
> Nevertheless, it would be nice to be able to support this on the
> server side leaving less hacks in post-review (and the positive side-
> effect that submitting the same change a second time would update an
> existing review).

Short-term, post-review might be your best option.

As for updating an existing review, you can use the -r flag. SVN, CVS, etc.
users all have to use this anyway for updating their review requests. You
just pass -r <review_request_id> on the post-review command line.

About patching RB to be less strict: I think the exception happens
> somewhere in the relational database mapping, so changing this would
> affect both the DB schema (which currently declares the changeset ID
> as an int) as well as plenty other places in the code which I
> currently cannot yet overlook being a novice to the RB code.

Sounds like a bunch of work would be needed, but hopefully it's largely

As for the DB change, we have a nice database migration system in place. You
pretty much need to just make the change to the appropriate Model class(es)
and then add an Evolution definition (see reviews/evolutions/*.py for

For a working development checkout and test site, you'd run:

$ ./manage.py evolve --execute

Or, if you install the new, modified Review Board, you can apply this to
your site by running:

$ rb-site upgrade /path/to/site

The next time anyone does an upgrade, they'll get the updated definition.


Christian Hammond - chip...@chipx86.com
Review Board - http://www.review-board.org
VMware, Inc. - http://www.vmware.com

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 
For more options, visit this group at 

Reply via email to