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 mechanical. 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 example). 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 -- 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 reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~----------~----~----~----~------~----~------~--~---
