Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
Kane Jeeves
Starting Member
2 Posts |
 Posted - 2008-12-08 : 09:24:29
|
| We finally moved to SS2005 and TFS. I now find out TFS doesn't integrate with TFS. So our developers will use TFS and our DBAs will use VSS? Hard to believe MS would make such a gaff. Is this what most folks do though (that try to stick with all MS solutions).Also, more importantly, do most folks keep actual physically different versions of dbs? On the programming side tools like TFS/VSS allow you to maintain various branches for different releases, etc. Seems to me that's nice but useless if there aren't corresponding physical db's to match the branches/releases of the code that access the dbs. Thoughts?TIA! |
|
|
visakh16
Very Important crosS Applying yaK Herder
52326 Posts |
Posted - 2008-12-08 : 09:28:08
|
| We maintain only codes of objects like sps,tables,views,trigger...in version control. Didnt maintain versions of db (mdf,ldf,..) as such in version control. |
 |
|
|
Kane Jeeves
Starting Member
2 Posts |
Posted - 2008-12-08 : 09:53:29
|
| So how do you handle, for ex, different versions of sprocs hitting against a single version of a table? For ex, Version 1 of SP_ABC has 2 params. V2 of the same SP_ABC now has 1 param and adds a join to a new table that didn't exist in V1 of the application. V1 is in production. V2 is under development. A bug is found in production V1. You can fix the SCRIPT for V1 SP_ABC, but as soon as you apply it to test the fix, you've screwed up SP_ABC for your V2 development (since there's only one physical SP_ABC in dev), which is counting on SP_ABC having 1 param and joining tables. |
|
|
|
|
|
|
|
|
Source Control for physical db's