rbt post for committed files in SVN

438 views
Skip to first unread message

john levin

unread,
Jul 15, 2016, 6:58:22 AM7/15/16
to reviewboard
 Hi,

I have two queries.

1. rbt post for committed files in SVN, as per guidelines "rbt post %SVNREVISION%" this works, but i'm unable to parse summary and descriptions along with this command it fails. Also it didnt considered if i write the summary and descriptions in .reviewboardrc file. Can you suggest any other alternatives if any?
2. Do we have a rbt command to update the reviews for committed revisions.
Example :- i have created a review with post-commit hook in svn. Now, i need to update the review. Again i'm gonna commit (which should update my review too). For this process i'm identifying with commit message comments. If Keyword "New" found then i will run "rbt post %SVNREVISION%". but for updating the reviews i couldnt find command that will update the reviews by taking the committed revisions.

David Trowbridge

unread,
Jul 15, 2016, 11:48:59 PM7/15/16
to reviewboard
John,

1. I'm not entirely sure what you mean "unable to parse summary and descriptions". Can you clarify?
2. What exactly are you looking to do when updating these? In a post-commit model, there's really one review request per commit, and any "updates" to prior changes are new commits that will get reviewed separately. Review Board is much more optimized for a pre-commit model where changes are iterated on before they're committed to a central repository.

-David

--
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.
For more options, visit https://groups.google.com/d/optout.

john levin

unread,
Jul 16, 2016, 4:57:18 AM7/16/16
to reviewboard
Hi David,
Actually I was validating both pre and post-commits.
OK coming to question number 1.
I'm running "rbt post" after the commits using revision number. In rbtools doc it was mentioned only "rbt post %rev%". I couldn't capture the svn commit message to pick it for reviews summary and descriptions (I couldn't find rbt command options to do so). Even it is not considering if I mention the summary and descriptions in .reviewboardrc file (it works perfectly for pre-commits rbt commands) . Do we have any options for posting reviews with descriptions and summary in post-commits.

David Trowbridge

unread,
Jul 16, 2016, 12:26:42 PM7/16/16
to reviewboard
What doc are you referring to that says "%rev%"?

rbt post does have --summary and --description parameters.

-David

john levin

unread,
Jul 16, 2016, 1:12:26 PM7/16/16
to reviewboard
Ahhh.. Actually i was parsing like

rbt post REV --summary "TEST" --descriptions "TEST" (i looked the doc, it says rbt post %REV% for committed files).
and getting Error: Too many revision.

But i didnt noted that summary and descriptions should be passed before the revisions ( Havent gone through the doc fully just looking on the syntax alone). So this worked.
rbt post --summary "TEST" --descriptions "TEST" REV.

Thank You David !

john levin

unread,
Jul 16, 2016, 1:21:41 PM7/16/16
to reviewboard
David,

For my Second question. I could understand that there is no option to update reviews in post-commit model (If not, pls help me to find out), then how can developers will fix the Open Issues ? You mean for Open Issues again a new review gets created ? 

David Trowbridge

unread,
Jul 16, 2016, 1:45:01 PM7/16/16
to reviewboard
John,

Theoretically you could upload the diff of the new commit as a new revision on an old review request, but the interdiffs won't make sense then. Review Board expects each revision of the diff to be the entire change. In a post-commit model, that usually means it's more appropriate for "fix up" changes to be a new review request that can point to the old one (either in the description or via the "Depends On" field).

The prevalence and annoyance of such "fix up" changes (in Review Board itself but also more generally in terms of keeping your branches stable and clean) is exactly why we prefer and highly recommend a pre-commit review model instead.

-David
Reply all
Reply to author
Forward
0 new messages