Thanks. By "use our API" do you mean using something like curl or a browser
REST client extension to make GET/POST calls?
On Wednesday, March 18, 2015 at 4:33:44 PM UTC-5, Christian Hammond wrote:
> Hi Justin,
> We support this, but generally only when you're using something like Git
> (or Git-SVN). Since Subversion has no native concept of individual
> uncommitted changes, we're limited in what we can do there.
> If you use Git-SVN, you can have a commit with one set of those changes,
> and another commit with another set, and can then post each commit
> Technically, if you can generate two patches (one for the first set and
> one for the second), then you can use our API to post the second patch for
> review, specifying the first patch as the parent diff. We don't have any
> support for doing this in rbt post though. (Though, I'd accept a patch
> adding a --parent-diff-filename= to do that.)
> Review Board - https://www.reviewboard.org
> Beanbag, Inc. - https://www.beanbaginc.com
> -----Original Message-----
> Date: March 18, 2015 at 2:29:38 PM
> Subject: Question about inter-request dependencies
> > I'm assuming this has been discussed before but I wasn't able to come up
> > with the right search terms to find it. Apologies if that is case.
> > I'm using RB 2.0.x with SVN, doing pre-commit reviews. I have two issues
> > work on: one refactors some redundant code into a new method and the
> > introduces a new code which calls the new method, and both are
> > in one source file. I submit a request with the diff for the refactor
> > start working on the new code that uses the new method. I want to submit
> > new request that depends on the first one, and only displays the new
> > Since I haven't committed the changes from the refactor (hasn't been
> > reviewed yet), my diff file for the new usage will include that
> > changes. I want the 2nd review request, for the new usage, to not
> > the diff that's already displayed in the request for the refactor. At
> > present the second request shows both change sets. I tried manually
> > removing the lines in the second diff file that were already submitted
> > the first, but RB threw an exception that the diff didn't apply cleanly.
> > Now some of you may ask, why 'jump the gun' and work on the new code
> > the refactor has been accepted? Valid point, but it's just an example to
> > illustrate what I'm looking for.
> > thanks,
> > -Justin
> > --
> > Supercharge your Review Board with Power Pack:
> > Want us to host Review Board for you? Check out RBCommons:
> > Happy user? Let us know! https://www.reviewboard.org/users/
> > ---
> > You received this message because you are subscribed to the Google
> Groups "reviewboard"
> > group.
> > To unsubscribe from this group and stop receiving emails from it, send
> > For more options, visit https://groups.google.com/d/optout.
Supercharge your Review Board with Power Pack:
Want us to host Review Board for you? Check out RBCommons:
Happy user? Let us know! https://www.reviewboard.org/users/
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/d/optout.