One thing I totally forgot about with my prior suggestion was the
relatively new exclude (-X/--exclude) functionality in rbt diff and post.
This might be a cleaner way to commit from root while weeding out the
I work under the same methodology where we have feature/bug-fix branches
and numerous commits to those branches before a review is initiated. But,
the way that we post to the review board server is that we merge back to a
trunk working copy and then initiate `rbt post` from there. Once the
review request is approved then we really merge back to trunk. While the
code has long been committed, from the rbt perspective the procedure is
that of a pre-commit review, and logically we think of it as a pre-commit
review before going to trunk. This works well almost all of the time.
There are sometimes a few hiccups with new or deleted files. Also, one
caveat is that this probably won't work too well if you are leveraging SVN
externals. That is really a shortcoming of the svn command lines tools,
but we've developed a wrapper around rbt to make it play nice with
externals as we leverage them heavily in our code base.
On Friday, April 10, 2015 at 6:23:52 AM UTC-4, Richard Parks wrote:
> Hi Griffin,
> You're absolutely right, I did narrow down by path but I think there must
> be something funny in our svn repo as a post commit from the root of the
> project failed, but a post commit from several folders within the root of
> the project worked fine.. I'll investigate this more later and report back
> if I find anything of interest.
> Your diff idea is neat as the diff from the root of the project worked
> (where the post failed) so this would be an acceptable work around in my
> Unfortunately due to the nature of our work most of the engineers in my
> team use post commit reviews across a revision range. This is simply
> because the features and changes we make often span >1 week and we can't
> risk not committing for that length of time. We all branch from trunk,
> feature add, review and then merge back to trunk, hence having to use post
> commit method.
> Cheers, Richard
> On Friday, 10 April 2015 02:02:33 UTC+1, Griffin Myers wrote:
>> Hi Richard,
>> Happy to help.
>> I don't think I have enough mileage with post-review commits to be much
>> more helpful here. My sense, although I could be wrong, is that posting
>> from the root is going to pull in *everything *within the revision range
>> (-r N:M) which may include commits from other developers that you are not
>> interested in and are not relevant to your review request. If you can't
>> narrow it down by path, which is certainly plausible based on an arbitrary
>> repo layout, then I'm not sure where that leaves you. Perhaps other folks
>> will have some suggestions?
>> One thing I might try, although this would not be an optimal suggestion,
>> would be to run "rbt diff" from root over the commit range of interest and
>> dump the diff to a file. Then manually strip the unnecessary files out of
>> the dump. Then run "rbt post" with the --diff-filename option. I've never
>> tried this, and even if it works it would likely become cumbersome really
>> quickly for large revision ranges which contain lots of irrelevant files.
>> On Thursday, April 9, 2015 at 8:48:02 AM UTC-4, Richard Parks wrote:
>>> Hi Griffin,
>>> Yes that got around it for me, particularly the "not generically point
>>> to the root of the repo." thank you very much for your help.
>>> In between there was another issue where it explicitly failed on a
>>> single file which it again complained about, but this was an empty file
>>> (i.e. size 0kB), being an empty file I removed it from the repo which fixed
>>> Whilst I've got the review posted now it would be nice (for me) if there
>>> was a way to post a review from the root of the repo as the changes I want
>>> to post for review span multiple folders within the same svn repo. Unless
>>> there is a way to post a review spanning multiple folders within a single
>>> repo? I've searched on here for that answer and couldn't find a way to do
>>> it. I did try posting a review then updating the review with rbt post -r
>>> ##### then the next folder path but this removed the original files for
>>> review (obviously).
>>> Thanks again Griffin
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.