What might be useful is if the mydbr_sync tool also extracted relevant config from related tables, and then also if it were able to import/reinstate this config into the database.
Having the sp_ content in version control is useful as far as tracking diffs, etc., but it doesn't help with deployment or escalation from dev to test to staging to live.
So another function of mydbr_sync should be to import an entire config bundle, being report defn's, sp's, and user/group/folder details -- that would really make it a 'sync' tool instead of just an extract tool as it currently functions. It would skip license and some of the other server-specific tables.
FYI we accomodate hard config differences in the config files by symlinking each file to a config directory higher in the folder structure. The entire mydbr structure then gets put into version control (only the symlinks are stored, not the actual content of the config files which are held in different repositories).
After development changes are made, we commit to version control and push to the test/staging/live servers. This is where having everything wrapped up in a config bundle (described above) would be ideal.
Currently we have to extract the sql and sync it into the database manually every time we deploy, so the usefulness of mydbr to us is always going to be measured against the pain of it not fitting into a typical deployment process. That is the challenge presented because mydbr stores some information in config files, and some in the database (like the license hash, which should probably be in a file).
Overall, however, a very useful tool! These improvements would be ideal.