This sounds like you are trying to manage myDBR as you would any other software, with development, test, and production environments. All environments need to be identical. Sadly, myDBR's update-du-jour can throw a wrench into the works.
Several years ago I solved this problem. I'm a little rusty on the solution details because I have not done much work in the area recently. But I'll try to give you as many hints as possible.
My development system was used for all myDBR updates and report/function creation/updates. The myDBR files were copied into a source library, SVN in my case. The report procedures and functions were created and maintained outside myDBR (in Eclipse and SVN.) I found it too easy to lose source if all development is done in myDBR. This places everything under source control. Table contents, such as mydbr_folders_priv, mydbr_folders, mydbr_reportgroups, mydbr_reports_priv, mydbr_reports and mydbr_styles were also exported as sql and managed by SVN. There may also be a few files in the mydbr user tree you will want to manage in your source management system.
To update a test system to match the development environment, my cloudy memory tells me I went to the top of the tree and did an SVN command to update the entire tree. (I may have actually maintained a tree for my code, and a different tree for myDBR's code.) This is where it gets hazy. I think, once I had updated the myDBR source into the tree, I could start up myDBR and run the update, without downloading their update-du-jour.
Then I had a php script that, after signing into the database, would update all the db procedures, functions and tables as if being done by myDBR. After that, testing could begin. The same process was used for all migrations, including into production when everything was approved.
This was a big time saver. Hope this helps.