One or two quick survey questions:
- Do you manage T-SQL scripts in source control?
- If so, which source control product / platform do you use?
:{> Andy
Note: I moderate comments, so your comment will take some time to publish.
One or two quick survey questions:
:{> Andy
Note: I moderate comments, so your comment will take some time to publish.
Yes, when I remember/am urged to, we use Subversion with the Tortoise front end.
1. Yes, always!
2. Depends what project I’m on. If I get the choice then its TFS & Datadude. At the place I am at the moment they use SVN for source control and author the scripts in SSMS.
Yes, absolutely. Subversion. Is there any other option?
Yes
Subversion
We do use Subversion for versionning. We hae some T-SQL script into this but it is not systematic. We use it mainly for SSIS.
Yes
Visual Source Safe (not my choice, and NO I don’t like it)… integration into BIDS is nice but other than that… junk.
Yes. Source Gear Vault.
Yep, 2 times a day, automated at 12:30 and 23:30
To a sourcesafe repository.
The triggers, views, functions and tables too.
We can rebuild a complete database (except for it’s data) from those snapshots.
Yes. Subversion is the king, much better that the alternatives.
I use source control for some of the T-SQL that I write. If it is ddl we always keep it in source control. If it is a personal query, I sometimes use it… depends on the project.
I currently use perforce. Until recently we used source safe (couldn’t get licenses for perforce and the two were the only approved source control tools).
one more for yes, subversion.
yes, whatever the client uses for source control. recent jobs include SourceSafe and TFS.
Yes, we currently store them in sourcesafe, I’m pushing to move to SVN.
Yes, we use Git in our shop
Yes, we use SVN.
Yes, I use TFS and the VSTS database projects. Autogenerating deployment scripts is worth it alone.
We use Visual Studio with Database Projects and our source control is from Seapine – it integrates alright – not as well as others I am sure.
1. Always. If the customer doesn’t have their stuff in source control, I put it there for them.
2. Whatever the customer is using. TFS, VSS, SVN (my favorite), and unfortunately CVS a couple of years ago.
Another happy TFS user here.
Subversion and TortoiseSVN.
+1 for svn
+1 for svn as well, but have to work with what the customer is using..
Absolutely. SQL is code. Code gets version controlled. QED.
Anyone who doesn’t organize their SQL into human-readable script files, just like their compiled code, should be taken out to the whuppin’ shed.
Which version control system? By force, VSS. Effective and over the last 15 years I’ve learned to cope with its faults and bugs. If I had a choice, it wouldn’t be VSS.
Looks like my previous reply was moderated away? We recently switched from VSS to SVN. I won’t say anything negative about this experience because maybe that’s why I was censored. 🙂
Hi Aaron,
Nope, just not published in a timely fashion.
:{> Andy
We use TFS for source control.
I have used subversion in the past, and presently I am using TFS – both come with some drawbacks – most importantly the lack of integration between them and SQL Server.
I have also created the folowing Connect suggestion – Native Source Control (Microsoft commented that they are thinking about it from the "tools perspective"). I would be really keen to get more suggestions about best approach to implementing a similar feature in SQL Server:
https://connect.microsoft.com/SQLServer/feedback/details/518835/native-source-control
TFS via VSDBPro – love it!
1. Yes, no, sometimes, depends … arrrgh
2. Currently bunch of T-SQL scripts with AnkhSVN in Visual Studio Pro. Also looking into the new SQL Source Control from Red-Gate (loving the SSMS integration).
Subversion/VisualSVN Server/TortoiseSVN
I use it for my views, functions and SSIS packages. Eventually I’ll be putting in some of our more frequently used queries that aren’t in there as actual views, plus some template/snippets. I’m not involved in creating any of the actual tables, so none of that’s in there.
I wouldn’t want to develop without some sort of version control for my SQL.
Yes. I’m actually amazed that so many places DON’T have the SQL code in Source Control.
Why is that? Is it because SQL is considered by some to be the red-headed stepchild of real-coding ?
I use VSS.
Barry, I think part of the reason is that a lot of people make changes by using the visual designers. If they don’t notice the Script button is there, they have little else to do but record a video of them pointing and clicking through the dialogs. 🙂
On a more serious note, I think some people use backups as their source control. After all, it can be complicated work to get a label to represent an autonomous point-in-time for a database, where all objects are in a consistent state. (I’m not saying it’s not do-able or worthwhile, just that it’s too much work for some people.) Whereas with a backup, you know that the contents (including data) were consistent at that point in time.
subversion, tortoise front-end
Yes, but badly. Using TFS.
1) Most definitely!
2) Does setting a script read-only on a shared drive count? My current place is a little more sophisticated and using TFS nowadays.