Thanks for your email. I think your understanding is correct.
We acknowledge that migration scripts are confusing and the current implementation is flawed in as much as it requires access to the source control system. The reason is that in order to fill in the gaps between the migration scripts, the SQL comparison engine needs to fetch the before and after states, which it currently fetches from source control.
We have just begun a project to remedy this. The solution will be to store the before and after states alongside the migration scripts themselves. Once this new architecture is complete, which is penned for the first half of next year, you will only need to reference the migrations folder (which you should check out as part of your build process) to leverage migration scripts. So if you have the migration scripts folder in your remote site, your batch file would use sqlcompare.exe and a switch to reference the migrations scripts folder.
Apologies that this isn't the way it should be right now, but hopefully we can remedy this in the coming months.