On 2012-12-13 18:27, Christian Hammond wrote:
I think it'd make sense for post-review to be able to populate the branch
name with the nearest origin branch, which is the typical pattern. Not sure
about the local branch being used, though.


I've been using the existing 'branch' field as the merge target branch (i.e. usually "master", but might be e.g. "release-0.4.x"). If we stuck the name of the review branch there instead, I'd feel like we have the opposite problem, i.e. wanting a field for the merge target branch.

Internally, custom data can be associated with a review request, but the
API for modifying this isn't there just yet. It needs to be added.

I guess I'm "raring to go", here. We would *really* like this support *soon* (we're at the stage of considering a switch from gerrit to RB, and having things like this available would make a better case for RB). I'm also more than willing (as I can find time, at least) to try to help with this. I'd love to poke around in the extensions API, for example, but the docs I've read so far, to be honest, I wasn't able to follow. What would really help is a code example or other basis from which to start poking around on my own.

(On a related note, one of these days I need to find out if I can send you my 'git-rb' script as a possible candidate for upstream inclusion, or at least a source of ideas.)

After 1.7, my plan is to start on better repository integration and DVCS
support, which would end up tracking branch information, amongst other
things. I have a post somewhere on reviewboard-dev explaining some of my
thoughts, if you have any specific requirements I should consider in my
plans.

Okay, I'll have to go look this up at some point. The main things I know we want, and that I think would be generally applicable, are:

- merge target branch (right now using existing 'branch')
- request branch (missing)
- request SHA (mainly for merge validation; would make some sense to put this in existing 'change request')

We're also going to want/need a few local fields, but not things that would make sense for inclusion in RB proper.

Ability to view individual commit diffs in a multi-commit request would be awesome (you probably know that already) but I expect that's a long way off (and gerrit doesn't support it either AFAIK) and not a priority for us.

--
Matthew

--
Want to help the Review Board project? Donate today at 
http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~----------~----~----~----~------~----~------~--~---
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


Reply via email to