Options
shared model = always up to date - Not true
allmhuran
Posts: 19 Bronze 2
I know SQLSC doesn't "support" branching, but I'd like to demonstrate that it isn't actually even compatible with branching, which will also hopefully provide some clues into what it would need to do to support (or be compatible with) branching in an upcoming version.
Imagine a scenario with developers working in a branch. Before merging their own code into the trunk (a reverse integraiton) they first need to merge the trunk into their branch (a forward integration). This is standard practise.
Since we can't do that in SQL Source Control, let's say the merge is performed by the team leader using TFS.
Now, SQL Source Control asserts that if a shared development model is used, each developer's source is always up to date. But that's not true. I just merged changes into the source using TFS. No developer has these changes in their local script repository.
It is also the case that the changes are not as yet applied to the shared development database.. it is only the scripts folder that has been updated via the TFS merge.
Let's say I have all the developers in the team do a "get latest" after I do the merge, which they do this via TFS. Now their local scripts are up to date, but out of synch with the development database.
How do we synch things up? Perhaps after perfomring the merge, the team leader should right click on the development database in object explore and choose "set as target", then pick the latest version from source control as the source, and perform an update via SQL compare, and then do a check-in. It seems circular, but also necessary. An artefact of the fact that when doing database development, you are always developing against a "built" version of what is in source control. That is to say, your DDL statements are always operating against a real database, not just code in source control.
But even this workaround can't be executed. If I right click and choose "set as target", the radio button to select "source control" as the source is disabled. One can only drag in another actual database as the source.
Imagine a scenario with developers working in a branch. Before merging their own code into the trunk (a reverse integraiton) they first need to merge the trunk into their branch (a forward integration). This is standard practise.
Since we can't do that in SQL Source Control, let's say the merge is performed by the team leader using TFS.
Now, SQL Source Control asserts that if a shared development model is used, each developer's source is always up to date. But that's not true. I just merged changes into the source using TFS. No developer has these changes in their local script repository.
It is also the case that the changes are not as yet applied to the shared development database.. it is only the scripts folder that has been updated via the TFS merge.
Let's say I have all the developers in the team do a "get latest" after I do the merge, which they do this via TFS. Now their local scripts are up to date, but out of synch with the development database.
How do we synch things up? Perhaps after perfomring the merge, the team leader should right click on the development database in object explore and choose "set as target", then pick the latest version from source control as the source, and perform an update via SQL compare, and then do a check-in. It seems circular, but also necessary. An artefact of the fact that when doing database development, you are always developing against a "built" version of what is in source control. That is to say, your DDL statements are always operating against a real database, not just code in source control.
But even this workaround can't be executed. If I right click and choose "set as target", the radio button to select "source control" as the source is disabled. One can only drag in another actual database as the source.
Comments
These are created when you commit changes using SQL Source Control.
Regarding any suggestions for changes to the way Source Control works, you should have a look at the SQL Cource Control Uservoice site.
http://redgate.uservoice.com/forums/390 ... ce-control