Working with Migration Scripts and Branching in SVN/SSC

muaddbamuaddba Posts: 18
edited May 11, 2012 11:52AM in SQL Source Control Previous Versions
We're using an SVN repository.

If I understand the documentaiton correctly, to branch in SSC/SVN, you copy the repository folder and link your DB to the new branch location.

Once I am done with my branch, to merge my changes back in, I am supposed to unlink my DB from the branch and re-link it to the trunk, and commit changes there.

It looks like this will require me to re-create any migration scripts I have made in the process of working on my branch, because those migration scripts are not going to be in the trunk, and I will no longer be connected to the repo branch where they exist.

Do I have this correct, or will they get incorporated somehow?
· Share on Twitter

Comments

  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    As far as I understand, with regard to migrations scripts on a branch/merge, everything should "just work".

    The way that SQL Source Control determines whether or not to apply migrations scripts depends on the extended properties that it creates in the new database after doing the "get latest".

    So you may want to check the database after the branching is done and see if the extended property specifying the migrtations location is set: 
    SELECT value FROM fn_listextendedproperty('SQLSourceControl Migration Scripts Location', NULL,NULL,NULL,NULL,NULL,NULL)
    · Share on Twitter
  • muaddbamuaddba Posts: 18
    thanks for the reply, Brian. Unfortunately, I can't link my production DB to source control, because that would be bad. So doing "get latest" there would not be possible. I have to use SQLCompare.

    I tagged 2 releases, release 1 and release 2, in SVN (which is essentially just making a copy of both the Schema folder and the Migration Scripts folder).

    I then did a compare of these two, but because the migration script was added somewhere in the intermediate steps between the final releases, SQL Compare doesn't seem to be picking it up.
    · Share on Twitter
  • David AtkinsonDavid Atkinson Posts: 1,458 Rose Gold 2
    There is currently no way of picking up migration scripts made on a branch. Both source and target need to belong to the same branch. Therefore if you are deploying using the latest from your branch as the data source, and a version on the trunk as the target, SQL Compare won't pick up any migrations scripts at all.

    The reason behind this is that we don't know how to migrate between branches. It's something we hope to look at soon.

    David Atkinson
    Product Manager
    Red Gate
    David Atkinson
    Product Manager
    Redgate Software
    · Share on Twitter
  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    Sorry, I was under the impression you would have a database and be able to get latest, like the instructions say to do.
    http://www.red-gate.com/supportcenter/c ... _and_merge
    · Share on Twitter
  • muaddbamuaddba Posts: 18
    Thanks for the responses....so can you tell me how you would propose to get these changes out to my production database(s) and include the migration scripts with them?

    Start me with the trunk, and I have a developer who needs to branch the code. What steps should we take, from development, to merging back to the trunk, to deploying to production, to get this to perform correctly and include the migration scripts?

    Thanks,
    Joe
    · Share on Twitter
  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    Apparently, the migrations scripts have to be recreated. Sorry for the inconvenience and the fact that nobody put this in the documentation. This graphic explains basically why it won't work. http://img27.imageshack.us/img27/1920/m ... nching.png
    · Share on Twitter
Sign In or Register to comment.