May 17, 2013 at 7:27 am
I've switched over to using SSDT for most of my DB Development.
Its been a really good (but slightly painful) change over.
Has anyone else done this?
May 17, 2013 at 8:34 am
In addition to developers' use of version control products in studios apps, we have a database trigger which logs all DDL changes. So every DDL change is logged into a table. In addition to the EventData() data we also log the Change ID initiating the change and any comments. So in production I know exactly when and why objects were changed.
May 17, 2013 at 9:43 am
call.copse (5/17/2013)
We are still non-distributed, and use SourceGear Vault, happy enough. Anyone got compelling reasons to go distributed?The only time I have not checked any code in recently is when a released version needs patching, an updated version is in progress, and we have not properly forked at release for whatever reason. This would rarely tend to happen to be fair.
From my standpoint the big reason is if you work disconnected at times with multiple people. Connectivity sometimes is an issue and distributed allows that to work better in my limited experience.
However if that's not an issue, not sure it matters. There is this: http://blogs.atlassian.com/2012/02/version-control-centralized-dvcs/
May 17, 2013 at 9:47 am
joe.eager (5/17/2013)
For users of the RedGate solution do you recommend Shared Database Development or Dedicated?I am leaning towards Dedicated, my coworker is leaning towards Shared.
dedicated.
Use a separate database for shared, and you and link that to the same project in VCS. That way you can work without disturbing others. If you break something, you don't break anyone else.
However when you commit in your dedicated database, do a Get Latest in the shared one to "integrate your changes" and test there. I assume you'll test in your dedicated before you commit changes.
May 17, 2013 at 9:47 am
chrisn-585491 (5/17/2013)
I use better version control (Git & Mercurial) for my open source projects than I do for my work related ones. Tis a sad thought...
🙁
May 17, 2013 at 9:50 am
My own answer:
I use Subversion in some demos, usually those set up early with the Red Gate tools. This was the first open source VCS we supported.
However I've been working with Git and GitHub and have started moving all my personal code and demos to there for tracking and backup.
Disclosure: I work for Red Gate,
May 17, 2013 at 9:57 am
"How many of you skip source control for certain apps? "
To be painfully honest, I do skip source control for some things.
For anything to goes into production or pseudo-production I use source control. For most of the heavy research I do, I also use a private source control library setup especially for me. For some quick and dirty stuff I write on this PC just to see if I can bend something construct to do something it is not really intended to do for curiosity sake, I may or may not keep it in source control, that depends on the outcome and the amount of effort required.
But there are throwaway pieces of code that I write in a stand-alone project that will be cloned or cut and pasted into another project. This is transitional stuff that does not have a long shelf-life and gets tossed in a few hours. Those are tossed before they ever see source control.
But most stuff that does not see source control are exceptions to the rule. Often now I will build a C# solution that have multiple projects in it, one being the production or candidate production code, any number of research projects, there also could be a few dlls, web services, and other objects like test harnesses of custom server side controls or the web services I develop. That all sees source control.
Summary - As a rule almost everything gets to source control, and I have a huge library of classes and objects I use to build new things with. I have to have that stuff under source control. And I find that I wonder more why I saved some pieces of code instead of wondering why I did not save something.
Not all gray hairs are Dinosaurs!
May 17, 2013 at 12:56 pm
I use Subversion for most things, but like Miles, there are things I do which are one-off throwaways that don't go into source control. Anything that might ever make it to production, absolutely.
____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
May 17, 2013 at 5:43 pm
joe.eager (5/17/2013)
I've switched over to using SSDT for most of my DB Development.Its been a really good (but slightly painful) change over.
Has anyone else done this?
We use SSDT here. It's better than the older DB Projects and free. Takes a little extra work and some learning, but I really like being able to just publish the "master" branch of our database project when we're ready to release. So much better than trying to maintain an ordered set of scripts across multiple branches, with (implied) dependencies on those scripts.
We use Git for our VCS. It allows us to work in a disconnected fashion, but doesn't track file moves/renames very well that I've seen. I'm probably just using it wrong, but that is one thing I do miss about a connected VCS. For personal stuff, I'll put a copy on SkyDrive or DropBox. I don't have anything that's so mission critical that I'd really be at a loss if they were down temporarily. For home files - Crashplan. I'd be a dead man if our pictures and documents folders disappeared or became corrupted. 🙂
May 20, 2013 at 4:52 am
Steve Jones - SSC Editor (5/17/2013)
call.copse (5/17/2013)
We are still non-distributed, and use SourceGear Vault, happy enough. Anyone got compelling reasons to go distributed?The only time I have not checked any code in recently is when a released version needs patching, an updated version is in progress, and we have not properly forked at release for whatever reason. This would rarely tend to happen to be fair.
From my standpoint the big reason is if you work disconnected at times with multiple people. Connectivity sometimes is an issue and distributed allows that to work better in my limited experience.
However if that's not an issue, not sure it matters. There is this: http://blogs.atlassian.com/2012/02/version-control-centralized-dvcs/
Thanks Steve. An interesting blog series there I'll go through a little more over coffee. It reinforces my feeling that currently we are doing OK. I do lie the multiple redundancy / work offline aspects discussed but for the dirt that would be kicked up in moving over right now it's not worth playing with. I'll keep monitoring our way of working though.
May 20, 2013 at 4:58 am
On the shared / dedicated model thing for Red Gate SC, we use shared and are totally happy with that route, despite the seeming preferences stated here. I understand why dedicated might be preferred - for the way we have always worked shared works well though - we are small and co-operate closely on projects, and are used to working on the same DB.
Just to give a slightly different viewpoint!
May 20, 2013 at 8:35 am
For those using a "real" version control system: When was the last time you tested a restore of one of your CVS backups?
CVS is an interesting choice in many shops - not every CVS system works well with large binary files, for instance Access databases or Excel files. To address the inevitable "but that's not code", a query in Access is no different than a query in a stored procedure, and a formula in Excel or Access is no different than one in T-SQL, C#.Net, C++, C, FORTRAN, Assembler, or machine language - it's still telling the machine to do math in a certain way.
As a "bare minimum" version control, some sort of dated copies are common. Using Par2 (http://chuchusoft.com/par2_tbb/[/url]) or another ECC tool is one step above, as that gives away to both identify and correct file corruption or unintentional changes.
May 20, 2013 at 9:27 am
We use Git and some of the files stored in version control are binary files that are essential for our SSDT projects to work correctly. We update them, the developers pull latest, and the projects work. If those files were corrupted, we'd have a bunch of errors in our projects because the cross-database functionality would break.
May 20, 2013 at 10:48 am
I think the author of the original post needs to learn the definition of the word trivial.
triv·i·al
/'trive?l/
Adjective
Of little value or importance.
(of a person) Concerned only with trifling or unimportant things.
So when I read his sentence I see, "Setting up local version control is beyond unimportant, benefits huge." Which completely doesn't make any sense to me.
Trivial does not mean easy.
May 21, 2013 at 8:56 am
All DDL and DML run against production databases is required to be in CVS. Same goes for source code (Java, PowerBuilder, etc.).
Viewing 15 posts - 16 through 30 (of 38 total)
You must be logged in to reply to this topic. Login to reply