|
|
Posted by Chad Richardson on 06/28/05 17:36
Erland,
Thanks for the explanation. I do have experience with source control tools
such as VSS and PVCS, but all have been for file/directory based source,
like VB. How do DB developers apply these principles (check in, check out,
etc.) to SQL Server? This is something I've curious about for a while now.
Thanks,
Chad
"Erland Sommarskog" <esquel@sommarskog.se> wrote in message
news:Xns96833C7C3BFCYazorman@127.0.0.1...
> Chad Richardson (chad@NIXSPAM_chadrichardson.com) writes:
>> Yes, very nasty. Luckily my hosting company (ReadyHosting) was able to
>> restore everything from their backup and the transaction logs.
>>
>> Normally, whenever I make DB table changes I save the scripts and put
>> them
>> in a "To Promote to Prod" directory, then use SQL Analyzer to apply those
>> changes to prod. But changes to views don't prompt for you to save these
>> changes as a script.
>>
>> What specifically do you mean by "the version control system"? (As you
>> can
>> tell by my question, I know just enough of SQL Server to be dangerous, so
>> any insight on how to handle version contol is appreciated.)
>
> "version control system" or "source code control" is nothing specific
> to SQL Server, but fundamentals of software engineering. In a version
> control system, developers adds their files. Later a file may be
> checked out, maybe by the same developer, maybe by someone else. The
> person who checked out the file, performs some changes to it, and
> then checks back in again, after proper testing.
>
> When it's getting time to make a build for an integration test, someone
> who is a "build master", "configuration manager" or similar puts some
> label on all the most recent versions of files, to create a baseline.
> During tests, bugs may be uncovered and fixed. The fixes can be inserted
> into that baseline, or a new baseline be created.
>
> Eventually, the thing is put into production and a baseline is created for
> this. Now, development of 2.0 starts. However, there may be need to
> fix bugs in production as well. Say that version 12 of file foo.cs
> was in the shipment baseline. By the time a critical bug in production
> is discovered, the file at version 14 for 2.0 development. But you
> check out version 12, and fix that, and check it in as 12.1 - you
> have now created a branch.
>
> The exact terminology for these various actions are different from
> product to product. The most commonly used version-control system
> in the Microsoft world is Visual SourceSafe. It performs branching
> different that about any other product. VSS has a lot of short-comings
> as a version-control system, but it's easy to start with, and it's OK
> for smaller teams.
> --
> Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
>
> Books Online for SQL Server SP3 at
> http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp
Navigation:
[Reply to this message]
|