How can we help you today? How can we help you today?
BobGood
Found the problem - wasn't the build (still failed after upgrade). I should have documented following steps above. Add change steps above to: 1a (add) Copy subversion branch to tagged branch for release. 6 and 7 used tagged branch to deploy from. Problem: Migration script includes a separate meta file with .migrationScript extension that has URL (and revision number) to the database script repository. I presume these are so SQL Compare can calculate the changes up to the migration script, then apply the migration script, and finally generate a script to bring the DB up to date. Essentially telling SQL Compare what the database should look like before and after the script. I'm not sure there is a reliable work-around to this one. While I can (and did) change the URL in the .migrationScript to match the new branch. This resulted in SQL Compare showing the existance of the script and including the wizard step to include it in the deployment. However the specific revisions referred to do not exist in that branch. It is easy to think of some scenarios where the result may not be as intended. So for the moment, deploying from a tagged or release branch using migration scripts is problematic. David, I hope the reason you are available so late is that you are on the west coast preparing for SQL in the City Seattle. Caught your presentations in Chicago and I recommend them to anyone doing version control or deployment. / comments
Found the problem - wasn't the build (still failed after upgrade). I should have documented following steps above. Add change steps above to: 1a (add) Copy subversion branch to tagged branch for re...
0 votes