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 Hammond - christ...@beanbaginc.com
Review Board - https://www.reviewboard.org
Beanbag, Inc. - https://www.beanbaginc.com
From: Justin Georgeson <baron.vo...@gmail.com>
Reply: email@example.com <firstname.lastname@example.org>>
Date: March 18, 2015 at 2:29:38 PM
To: email@example.com <firstname.lastname@example.org>>
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.
> 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 to reviewboard+unsubscr...@googlegroups.com.
> 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.