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
