Re: Question about inter-request dependencies

2015-03-23 Thread Stephen Gallagher 
On Wed, 2015-03-18 at 14:33 -0700, 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.)

I don't know if it's accidental, but 'rbt post commit_id' actually 
works for this case. I use it all the time.

If I have three commits in my branch from upstream/master, I can look 
at 'git log' and then do
rbt post commit_1
rbt post commit_2
rbt post commit_3

And they all seem to do the right thing. It's been quite handy :)

-- 
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.

Re: Question about inter-request dependencies

2015-03-18 Thread Christian Hammond 
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 - christ...@beanbaginc.com  
Review Board - https://www.reviewboard.org  
Beanbag, Inc. - https://www.beanbaginc.com

-Original Message-
From: Justin Georgeson baron.vo...@gmail.com
Reply: reviewboard@googlegroups.com reviewboard@googlegroups.com
Date: March 18, 2015 at 2:29:38 PM
To: reviewboard@googlegroups.com reviewboard@googlegroups.com
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+unsubscr...@googlegroups.com.  
 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.