The problem being addressed here is using the ReviewBoard to post changes against a subcomponent that is maintained in a vendor branch [http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.advanced.vendorbr]. The problem here is that with sufficiently large subcomponent, the modifications between two releases of this subcomponent are too big and what's worse, nobody is interested in reviewing them in their entirety.
Here's an example. My project X contains a somewhat modified Linux kernel in the linux directory. I import new Linux releases in a vendor branch, at ^/vendor/linux/*release*. Now say, I am upgrading Linux from 4.1.27 to 4.4.14 (svn merge ^/vendor/linux/{4.1.27,4.4.14} linux) and making some modifications inside my code in Linux tree (linux/arch/newarch + some of the stock Linux files e.g. linux/init/main.c) as well as changes in the other components to accommodate the kernel upgrade.
If I now just run rbt post in the working copy, the review request ends up with ~50 pages of diffs. Here comes the idea for the new option, --svn-diff-origin: none of the reviewers are really interested in the changes in the Linux kernel itself. Rather, what's interesting is

- How our stuff inside Linux kernel has changed (linux/arch/newarch)

- What are our modifications to stock Linux files with this release (linux/init/main.c)

- How our other code had to change to accommodate the upgrade.
This new option allows one to override what is considered a "source" part of the diff for certain directories. For example, in this case one would invoke rbt post as:

rbt post --svn-show-copies-as-adds=n \
    --svn-diff-origin linux ^/vendor/linux/4.4.14 \
    --svn-diff-origin linux/arch/newarch ""


This will produce a diff for the linux subdirectory against the pristine Linux 4.4.14 sources - while reverting to the normal rbt post behavior for linux/arch/newarch.
Comments, thoughts?

At this stage, this is a request for comments. If there's an agreement such feature will be useful, I'll add the tests.