explicit revision number may destroy target database
I have noticed that when using sqlcompare command-line with parameters:
/sourcecontrol1 and /revision with a specific revision number, if that number does not happen to be a changeset that includes changes to the scripts folder in Source control, SQL compare seems to generate an empty DB as the source of comparison. This results in generating a script that drops everything on the database.
I am looking at this scenario for automation from a build server (TeamCity in this case). I wish to pass explicity the revision number (there's a team city variable suited for that) rather than using HEAD as it seems conceptually more appropriate (in case something is checked in between the moment the build started and when it gets to actually run SQLcompare.exe, as I would have several other build steps before that).
I have been able to replicate the same issue with the GUI SQL Compare, I just put an explicit revision number that is a code check-in (not database objects), and I get everything marked as 'drop' in target db.
My latest changeset in numbered 6639. My latest changeset of DB objects was 6634. If I use /revision: with a number between 6635-6639, it yield what I described above.
My source control is Vault Standard.