On Jun 10, 2013, at 12:01 PM, Matthew Woehlke <mwoehlke.fl...@gmail.com> wrote:
> On 2013-06-10 13:32, Allan Caffee wrote:
>> Is any way to have code automatically committed/pushed to Subversion/Git
>> once a requisite set of users have given a review a ShipIt! I believe some
>> other code reviews support this and I was curious if anyone has attempted
>> this and whether it's something the ReviewBoard community would be
>> interested in.
> AFAIK there is not such a tool at present. I for one would definitely be
> interested in having one available.
> That said, I don't think it is going to be possible right now for git (unless
> you are doing only pre-commit review without a 'branchy' workflow, which is
> probably less common) as there is not a standard way of recording the branch
> head that you could use to perform a merge. (This is *VERY* high on my wish
> What might be manageable in the current framework would be if there is some
> way to stuff the SHA that matches the request into the changenum field. >From
> this it is possible to derive the symbolic name of the branch (i.e. for
> pretty merge commit messages). At any rate, you want the SHA no matter what
> as it ensures that what you are merging actually matches the request.
> For svn, it is easier because you aren't dealing with an existing commit. In
> either case you are probably talking about separate tools/extensions at least
> for git and svn, possibly even two different ones for git (for pre- and
> post-commit review).
This feature is something we've talked about, but there's not a great way of
achieving it in all cases, at least to a level we're comfortable with.
The problem boils down to three main things:
1) Handling authentication. Every user would need to store their auth details
or SSH keys, and there's a lot of thinking that must be done there, plus we'd
need to start coming up with different scenarios for who can push and how.
2) Having a checkout available. Not required in all cases, but at least with
Git, where this is often wanted, you would need a full clone in order to push.
3) Handling merge conflicts. We wouldn't provide conflict resolution, so it'll
often be easier just to do this outside Review Board. (Otherwise, people would
just get annoyed when merging doesn't work all the time.)
Now, there are some things we can do with hosting service APIs, in theory,
maybe. There's been talk of a big Merge button that merges a change in, if the
API gives us the ability to do that. Still, even there, we have to solve a
number of problems.
Basically, it's just not something we'll be getting to any time soon. We don't
really want to be your front-end to your SCM or your patch merge tool. We want
to be your review tool. That's where our focus is right now, and we're working
on things to improve that. Maybe down the road, we'll figure out a good
solution to pushing code.
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
Beanbag, Inc. - http://www.beanbaginc.com
Want to help the Review Board project? Donate today at
Happy user? Let us know at http://www.reviewboard.org/users/
To unsubscribe from this group, send email to
For more options, visit this group at
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/groups/opt_out.