Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««1234»»

The Control Poll Expand / Collapse
Author
Message
Posted Friday, May 17, 2013 9:50 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 4:55 PM
Points: 31,278, Visits: 15,736
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,







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1454074
Posted Friday, May 17, 2013 9:57 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: 2 days ago @ 10:15 AM
Points: 2,464, Visits: 1,551
"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!
Post #1454077
Posted Friday, May 17, 2013 12:56 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: 2 days ago @ 7:49 AM
Points: 143, Visits: 263
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.
Post #1454175
Posted Friday, May 17, 2013 5:43 PM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Yesterday @ 10:02 AM
Points: 851, Visits: 1,345
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. :)



Post #1454213
Posted Monday, May 20, 2013 4:51 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: 2 days ago @ 1:43 AM
Points: 1,773, Visits: 1,168
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.
Post #1454482
Posted Monday, May 20, 2013 4:58 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: 2 days ago @ 1:43 AM
Points: 1,773, Visits: 1,168
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!
Post #1454483
Posted Monday, May 20, 2013 8:35 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Wednesday, November 19, 2014 12:06 PM
Points: 887, Visits: 2,453
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/) or another ECC tool is one step above, as that gives away to both identify and correct file corruption or unintentional changes.
Post #1454563
Posted Monday, May 20, 2013 9:27 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Yesterday @ 10:02 AM
Points: 851, Visits: 1,345
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.


Post #1454589
Posted Monday, May 20, 2013 10:48 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Thursday, September 18, 2014 6:41 PM
Points: 1,733, Visits: 1,071
I think the author of the original post needs to learn the definition of the word trivial.

triv·i·al
/ˈtrivēə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.



Post #1454633
Posted Tuesday, May 21, 2013 8:56 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, December 17, 2013 12:58 PM
Points: 39, Visits: 30
All DDL and DML run against production databases is required to be in CVS. Same goes for source code (Java, PowerBuilder, etc.).
Post #1455066
« Prev Topic | Next Topic »

Add to briefcase «««1234»»

Permissions Expand / Collapse