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 > separately. > > 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.) > > Christian > > -- > Christian Hammond - chri...@beanbaginc.com <javascript:> > Review Board - https://www.reviewboard.org > Beanbag, Inc. - https://www.beanbaginc.com > > -----Original Message----- > From: Justin Georgeson <baron...@gmail.com <javascript:>> > Reply: revie...@googlegroups.com <javascript:> <revie...@googlegroups.com > <javascript:>>> > Date: March 18, 2015 at 2:29:38 PM > To: revie...@googlegroups.com <javascript:> <revie...@googlegroups.com > <javascript:>>> > 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 > to > > work on: one refactors some redundant code into a new method and the > second > > introduces a new code which calls the new method, and both are > implemented > > in one source file. I submit a request with the diff for the refactor > and > > start working on the new code that uses the new method. I want to submit > a > > new request that depends on the first one, and only displays the new > code. > > 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 > refactoring > > changes. I want the 2nd review request, for the new usage, to not > display > > 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 > in > > 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 > before > > 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: > https://www.reviewboard.org/powerpack/ > > Want us to host Review Board for you? Check out RBCommons: > https://rbcommons.com/ > > 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 > an email to reviewboard...@googlegroups.com <javascript:>. > > For more options, visit https://groups.google.com/d/optout. > > > > -- Supercharge your Review Board with Power Pack: https://www.reviewboard.org/powerpack/ Want us to host Review Board for you? Check out RBCommons: https://rbcommons.com/ 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 an email to reviewboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
