Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
rnbguy
Constraint Violating Yak Guru
293 Posts |
 Posted - 2007-02-22 : 01:48:24
|
| What [if any] are the best source safe options for both sql server 2000 and 2005? |
|
|
khtan
In (Som, Ni, Yak)
17689 Posts |
Posted - 2007-02-22 : 01:57:19
|
There has been several discussion on this. Do a search for 'source safe' or 'source control' or 'version control' in this site.
KH |
 |
|
|
rnbguy
Constraint Violating Yak Guru
293 Posts |
Posted - 2007-02-25 : 19:34:40
|
| yeah ive noticed quite a few commments and have read iteresting comments by members particularly kristens comments...however it may just be me but doesnt adding source control for stored procedures seem like a burden? i mean if u make a change to the stored proc on dev server and it doesnt work u can always revert back ur changes etc... im sorry i dont quite see a situation where source control would be helpful... i know its just me actually but could someone shed some light please? |
|
|
|
nr
SQLTeam MVY
12543 Posts |
Posted - 2007-02-25 : 20:30:31
|
| >> i mean if u make a change to the stored proc on dev server and it doesnt work u can always revert back ur changes etc... But what if you've made a lot of changes and only want to reverse some.What if you make a change which works then want to try something else which might be better? You check in tpo source safe then try your new version knowing that you can always go back to the previous version.If something goes wrong with the code you can always compare with what is in sourcesafe to see what you have changed.If something is wrong in production (or dev) you can look in sourcesafe to see what has been changed to see if someone has messed up.When you are working on an SP you check it out of sourcesafe so that everyone esle knows that you are changing it and they are stopped from making changes.You can label your changes as complete so that others know that you have completed your work on it.There are lots of advantages to using sourcesafe (or at least a source control system) which as you gain more experience you will find invaluable.==========================================Cursors are useful if you don't know sql.DTS can be used in a similar way.Beer is not cold and it isn't fizzy. |
|
|
|
Andraax
Aged Yak Warrior
790 Posts |
Posted - 2007-02-26 : 04:35:14
|
| Source control is also a must-have as your project/organisation grows. A project with several members working on the same objects without source control is total madness. |
|
|
|
Kristen
Test
22859 Posts |
Posted - 2007-02-26 : 06:02:53
|
| "i mean if u make a change to the stored proc on dev server and it doesnt work u can always revert back ur changes etc..."How would you "revert back" without some sort of version control system?We used to rename files with date & time extensions, take ZIP files every hour, and all sorts of "hacks" like that.Now we just work as normal and if we need to revert to an older version we just get it from the Version Control systemKristen |
|
|
|
rnbguy
Constraint Violating Yak Guru
293 Posts |
Posted - 2007-02-26 : 20:43:32
|
| right, just wanted opinions, thanx again i will also raise these in todays meeting |
|
|
|
jezemine
Master Smack Fu Yak Hacker
2886 Posts |
Posted - 2007-02-27 : 02:42:06
|
source control is ESSENTIAL in any real development org.this little app of mine will help you get all your objects in source control if they are not already: http://www.elsasoft.org/tools.htm
www.elsasoft.org |
|
|
|
Kristen
Test
22859 Posts |
Posted - 2007-02-27 : 04:29:22
|
rnbguy:Its a bit hard to express into words, but I'll have a try.I've been software engineering for years. We had a nice little DOS based application hundreds(!) of years ago that stored file changes in a "differences" file, and that passed for source control.And then my skill set changed to SQL, and when we started using Stored Procedures we stored each one in a separate file (rather than just changing them in the database directly - which strikes me as being nuts and, sadly, all too commonplace ....)So at least we had them organised into Folders by project and so on.Given that I do know about Computer Engineering it annoyed me that we didn't have any proper Source Control. So it was at the top of my list to get that sorted out ... for probably 3 years  Eventually we found some slack time in our schedule, installed Sub Version, and I experimented with how to use it.I also took the trouble to find every renamed file, ZIP file, backup, and so on; carefully "unzip" them in chronological order, and Commit each "batch" to Sub Version so we had a reasonable history [before we started using it in anger]. It was back breaking, soul destroying, work, and took several more months to find the slack time and so on. Anyway, it did mean that we started off with over 200 "versions" in the repository.It would have been much better to have installed Sub Version from Day One  . I knew that back then, so I couldn't cry over.So then we had Sub Version in place. Each developer had a copy of the source code on their C: drive (which gives us additional redundancy), the source control repository gets backed up to tape, and we have 20 generations of the repository in on-line copies (just in case something gets corrupted and the tape backup hasn't picked it up, we need more restore-granularity than the tapes, whatever - I'm a Belt&Braces sort of person!)And now we rely on it in a number of way ...... whenever I commit my own work I get the chance to DIFF it against the previous version. This forms the basis of my own peer-review of my own work.Whenever I Update my local copy (with other people's changes) I DIFF their changes too - so I can peer review their work.We have DEV and SHIPPING branches - we DIFF all the DEV stuff into the SHIPPING branch at each major roll-out (and then Commit those changes to the Shipping version into Sub Version).We make ad hoc changes to the Shipping version for bugs found during the roll-out process. These are more stringently checked so that some half-arsed quick-fix changes don't get released During the lifetime of a "version" we may selectively DIFF the DEV branch into the SHIPPING branch. This then makes a Service Pack version of the [then current] SHIPPING version.And at any time we can pull out all the source code for a previously-shipped version, and thus get an exact copy of the source code as it was when we rolled it out to a particular client.A couple of things we specifically do, that relate to Sub Version but may be relevant to other Version Control systems:Sub Version works on the basis that you Check Out all the files you want. By default they are NOT locked. You can work on anything you like (including off-line on your Laptop, whatever), and then you Check-in [referred to in Sub Version as COMMIT] your changes. I prefer this to the "Check-Out and Lock" style of Source Safe. Yes we get two people work on the same file at the same time. So what ... it happens about once a month, the second person who tries to Commit has to merge their changes with the now-newer version in the repository to "Resolve" the difference.We always COMMIT ["Check In"] before we UPDATE ["Re-Check Out"]. COMMIT will complain if the Repository version is more recent than your local copy (and in fact it rolls back the whole Commit), so then you know that you have file(s) in "Conflict". You can then "Resolve" these differences.However, if you "Update" first to Freshen your local files and there is file(s) in conflict, then Sub Version will just merge the differences into your file (its pretty intelligent about this, so it only does it when the changes are not close to each other, and it usually gets it right). HOWEVER, that act of merging disguises what your original file looked like (it creates copy files of before/after/during/whatever, but we find that rather annoying so we do the "Commit first" to flush out if there are any Conflicts.The other thing that I find a bit annoying, but I probably haven't really got the hang of it, is branching the code. That causes Sub Version to want to make a whole-other-copy of the code on my C: drive. (There is only one copy of the file in the Repository until there is a real change & difference in the two branches, so no wastage there). Anyway, that needs a bit of thought and planning, so best to make some trial Branches when you are first experimenting to see what works - if you Branch a whole multi-megabyte source code repository, and you get an unexpected outcome, you are either stuck with it forever, or you have some very brave "delete and restore" choices to make!Single Developer, Multiple PCs : I have my source-code on my PC, and also on a Laptop for the rare-ish occasions when I'm out-of-office. A PC @ work and another @ home would be a similar scenario. It gets confusing as to what was updated where, as all of it is only attributed, in Sub Version, to my initials. I suggest in those circumstances you may want to have some pseudonyms for the users, so that changes can be attributed to both the Source Computer and the user. (What Sub Version refers to as "Blame" - which strikes me as a rather unfortunate term!)Permissions is the final thing. Sub Version lets you have lists of users, groups, and so on. But they are all in a plain text file on the server - make sure that everyone doesn't have access to that.But my one key piece of advice: Install version control one day one. If you are reading this and don't have it yet, get it installed. Its a PITA to install later in the project, and its a godsend and without the single most time saving and important tool we used but, like many good things, its a back-room service and an unsung hero!Kristen |
|
|
|
|
|
|
|
|
Source Safe