September 13, 2015 at 9:16 am
We store all our Sprocs, Triggers, Views etc. in separate files, and those are stored in a Revision Control System - SVN in our case, but I'd like to upgrade to a distributed system so I can commit locally.
I started out with Dave Burton's TLib[/url] - looking at my repository I find that it goes back to 1986 ... and the EXE folder includes this example file from Valentines Day 1985 🙂
.S GOODBYE.X 14-Feb-85 Dear John letter
.I 5
Dear John,
I'm sorry, but I don't love you anymore. I've found someone
new. I'll always remember the special times we've had together.
Love,
Mary
.S GOODBYE.X 14-Feb-85 Dear Mark letter
.I 1
Dear Mark,
.C 2 5
Seems to me that the alternative is to just right-click a Stored Procedure in SSMS and say EDIT and then EXECUTE when I am ready. Is that about the Top & Bottom of it?
Hopefully I'm preaching to the converted ... if not and folk do use the RightClick-Edit in SSMS then do please stir-your-stumps and get some Revision Control installed. Anything will do to start with, migrating to a different tool is a pain, but rather than prolong the choice process I think more important to get something installed and consider if there is a Better Alternative later.
EVEN in a one-man-band shop.
Assuming RightClick-Edit in SSMS / no Revision Control system installed:
1. Two people editing, by chance, the same SProc are "latest-save wins" and earliest-save is "all code changes lost"
2. Nightmare to rollout from DEV to TEST and then PRODUCTION. I suppose such folk would use a Database Changes Difference tool, like RedGate's. maybe that works Just Fine? Our SProc scripts include EXECUTE Permissions and sometimes a "INSERT this CONFIG row if not already exists" - none of that would be in a Datbase DDL DIFF script. We also have an SProc call at the top of each SProc Create Script to "log" that the script was run, and what version of the Sproc it is (we basically just use 'YYYYMMDD' as the version number). We can query the Log to see which version of the script was run/when, and compare that against DEV / TEST if we need to. It also shows (a high count on) days when we did a rollout, which is sometimes a useful clue / aide memoire.
We create a rollout script by concatenating all individual files that have a Modified Date more recent than the last rollout. Sometimes the sequence of execution means we get an error because "B is before A" in which case we rearrange the individual pieces within the rollout script and run it again until it runs clean. Fair chance that if it ran clean on TEST it will similarly run clean on PRODUCTION. We have APPs used by lots of clients, so a rollout to production, for us, is "lots of servers" rather than just one, in-house, one.
3. We do, occasionally, go back and compare code from an old version to figure out how a new bug has crept in particularly when we can associated it with "Something must have changed on THIS date"
4. I peer-review all code by juniors (using the Revision Control System to compare original-version and recently-checked-in-version). There is no-one to peer review my code, so I use the CHECKIN process for that job - easy enough, during checkin, to right-click each file in the Check In list and use the "DIFF against most recent version" to see what changes I made and double-check that they make sense!! If a day or two has elapsed since I actually made the change, and thus I am seeing it with fresh eyes, so much the better. I think that would work in one-man-band shops too.
5. We have
/**DELETE
...
DELETE**/
markers in our code (hopefully I'm not alone??!!). With Revision Control I can be aggressive deleting them as I know I can retrieve them from repository if I need them again. Thus if I see them in a Peer Review I know that the "verbose" version is already in the repository so I can clean-up the code, check it in again, and we are then running with minimalistic code.
6. Code Collisions, when two people edit at the same time, don't matter. The second person to check-in gets to do a merge (in fact SVN will usually suggest an automatic merge where the code changes don't trip over each other within the single file)
7. Then there is code branching. Maintain service pack fixes to Production code whilst simultaneously carrying out new development work on Production. That must be a nightmare without Revision COntrol
September 14, 2015 at 12:00 am
Comments posted to this topic are about the item The History of the VCS
September 14, 2015 at 6:24 am
A not-often-mentioned benefit of VCS is the ability to organize work. All the parts of a solution from data store to GUI can be kept in one place for easy reference or retrieval. VCS can also version things other than source code, so including design documentation and tracking its evolution is a snap.
I will admit I learned that the hard way and have recently embarked on a process of consolidating parts and pieces into a single repository per solution to keep myself sane.
____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
September 14, 2015 at 7:32 am
Started out on Source Safe. Now using Subversion. Don't like the merging at all because of development decisions made on code that may not be there when you check it in as someone else has changed that part. So we all try to avoid it if possible.
September 14, 2015 at 7:36 am
That's what's really important; you need to use the system and track your code. It's frees you as a developer, allowing you to clean up your code, remove excess comments, and easily find out what worked (or didn't) in previous code.
I really hope the "excess comments" you're talking about are the old commented out code and not comments in general.
One of the things I HATE about reading other people's code is lack of comments. In my own code I literally have 75% comments and 25% code.
As a result, yes, I have to write two programs, one in code and one in English, and I do have to expend the effort to keep the comments up to date and YES it does take extra time up front.
But when you go back two years later and try to upgrade the code it's a hell of a lot faster than if the comments weren't there!
Oh, and I use TortoiseSVN, VCS software is a godsend!
September 14, 2015 at 7:54 am
We currently use TFS for version control of application and database code. Coupled with that each developer has their own development server (VM) to work with. Although we have had some rollbacks over the two and on-half years I have been here they have been few and far between.
I especially like the ability to test deployments using TFS to validate I am not going to break the database environment. All files are stored in TFS and are accessible to all developers. If a given stored proc is needed for any reason not only is the latest version available but all historical versions are available.
September 14, 2015 at 8:40 am
I'd like to know how people save the stored procs, views, triggers, etc. in a VCS? Whenever I've used SSMS there wasn't any integration I could see with anything like Visual SourceSafe (at my old job) or TFS (at my new job). However if we used SSDT and then used projects within SQL, I can see how that might work. So do you use SSDT in order to stored your SQL code into a VCS?
Kindest Regards, Rod Connect with me on LinkedIn.
September 14, 2015 at 8:47 am
Rod at work (9/14/2015)
I'd like to know how people save the stored procs, views, triggers, etc. in a VCS? Whenever I've used SSMS there wasn't any integration I could see with anything like Visual SourceSafe (at my old job) or TFS (at my new job). However if we used SSDT and then used projects within SQL, I can see how that might work. So do you use SSDT in order to stored your SQL code into a VCS?
I use TortoiseSVN. It doesn't integrate with SSMS but it does integrate to Explorer, so I usually keep Explorer open on one monitor and SSMS open on the other. Works very well.
September 14, 2015 at 8:49 am
I (not surprisingly) use Redgate's SQL Source Control..
I have in the past worked as Rod has and kept a VCS client open along with my SSMS. In those cases, we essentially work from a folder in the file system, opening and saving code from there.
September 14, 2015 at 9:22 am
Rod at work (9/14/2015)
I'd like to know how people save the stored procs, views, triggers, etc. in a VCS?
No idea if my way is suitable for large / multiple projects, or even if it is a GOod Way, but in case helpful I do this:
C:\SVN root folder
Projects extracted under this folder.
On my laptop I thus have [a copy of] all relevant source code and I can work offline with no connection to "back home"
I open files in SSMS (or any editor), modify them, execute them, save them. I create new files similarly. I NEVER rename a file (via Explorer / RightClick, F2).
I use Tortoise which allows me to COMMIT files using Explorer - select a bunch of files and RightClick Commit. In fact I can do that from the File Open dialog box in SSMS - just RightClick a file, or go up-one-level and then RightClick the containing-folder, and then choose COMMIT (or any other Tortoise command in the Context Menu)
I usually check in a single file or two, or a whole folder (or I COMMIT from the root SVN folder to make sure everything is committed).
I always commit-before-update. If I commit a file that someone has changed I get a warning. If I UPDATE, instead, SVN merges their changes with mine, which I find hard to then sort out. So instead if I get the warning I abort the Commit and use DIFF to merge their changes with mine and then commit.
When I have committed everything I then UPDATE to get everyone else's changes into my local copy
If I want to rename a file I use RightClick and then the Tortoise Rename. That presents the original filename in an editable formfield.
I use the (extremely powerful) DIFF tool which is part of my Programmer Editor (command line for DIFF is configurable in Tortoise). Tortoise provides single click for COMMIT or UPDATE and 2-clicks for rename, a variety of other functions, and DIFF against most recent version (which I use now-and-then to check whether the changes I have made look OK against the original), and 3-clicks to first get a history list of commits and then to DIFF against a specific earlier version.
Once in a blue-moon I use BLAME to see each individual change attributed to the ID of the person that made it - e.g. if sorting out some conflict between multiple users' changes.
September 14, 2015 at 10:15 am
roger.plowman (9/14/2015)
One of the things I HATE about reading other people's code is lack of comments. In my own code I literally have 75% comments and 25% code.
I struggle to get into a zen state where my code is perfectly intelligible without any comments. Functions that do only what their name is, no hidden processing effects, obvious property methods that completely encapsulate their own handling. When you see a comment in my code, it is an admission of defeat--I have given up trying to make this code perfect.
September 14, 2015 at 11:24 am
I love and hate git, but it is the only way I can imagine managing a couple dozen dev teams around the globe committing to common DB repos without going insane(r). We use it as our primary gatekeeper for our pre-production environment. Nothing can get to preprod without going through teamcity deployment pipelines that pull directly from git.
September 14, 2015 at 12:38 pm
GeorgeCopeland (9/14/2015)
roger.plowman (9/14/2015)
One of the things I HATE about reading other people's code is lack of comments. In my own code I literally have 75% comments and 25% code.
I struggle to get into a zen state where my code is perfectly intelligible without any comments. Functions that do only what their name is, no hidden processing effects, obvious property methods that completely encapsulate their own handling. When you see a comment in my code, it is an admission of defeat--I have given up trying to make this code perfect.
Love this, clean code over comments, if anyone doesn't agree please read the "clean code" book and let's talk :).
September 14, 2015 at 1:21 pm
Ed Elliott (9/14/2015)
Love this, clean code over comments, if anyone doesn't agree please read the "clean code" book and let's talk :).
lol yeah. One of my zen tricks is error handling. Error messages are a great way to document code.
September 14, 2015 at 1:26 pm
I'll be honest: I currently do not use a version of VCS. I did back in the Dos days using BRIEF, someone came out with a source control package called Sourcerer's Apprentice that integrated quite nicely. I tried to get VCS at my previous gig but it never happened. At my current gig, I'm more optimistic. I'm going to the Denver SQL Saturday this weekend and doing the pre-con session on DLM and I'm hoping that'll give me the information that I'm looking for to get some tools.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
Viewing 15 posts - 1 through 15 (of 29 total)
You must be logged in to reply to this topic. Login to reply