Related
Our dev team uses VS.NET for app development and TortoiseSVN/VisualSVN for version control. It seems that almost every day issues arise with the working copy or the repository getting screwed up, and folks just throw up their hands and call me when it happens. There are definitely human factors at work (SVN works as it should) but I'm tired of playing SVN helpdesk to the dev team. Can anyone recommend a better/more intuitive setup for version control?
Agent SVN works well for me. It integrates nicely with Visual Studio.
SVN is about as simple as version control systems get. Problems should only arise when dealing with merging operations...those can be tricky.
If you don't address the "human factors" it won't matter which version control system you use, you will always be the helpdesk. To address these kinds of problems, you typically need to:
Set up a wiki with common "recipes" for version control tasks.
Include a workflow diagram for how changes are made to your code (for those who don't like to read).
Host a training session that is specifically
designed for your users (use the wiki
material).
When helping someone with a problem, be sure to make them perform the actual fix. Don't just do it for them, talk them through it instead.
Make a point of directing users to product documentation when helping them.
Introducing a new version control system into any organization should include the items I listed. I realize it is extra work for those who get it done, but it does save you from long "support" hours down the road.
Can anyone recommend a better/more intuitive setup for version control?
Better? Yes. More intuitive? That's debatable. Look into distributed version control software, namely Mercurial or Git. Both have freely available plugins to integrate with Visual Studio. And if you can manage spending a little money, I've heard very good things about Fog Creek's Kiln.
As for your issues with SVN, I have a couple tips. The first is to make sure you keep everyone synced on the same version of the product. It tends to update frequently, and so this can be tricky, as you also don't want to fall too far behind the current version. The second is that we used to have big problems with Tortoise trying to cache icon overlays on mapped network drives. There is an option you can turn off somewhere that suddenly made things way more stable. But that was at my last job, and I don't remember the exact setting any more.
I think you already gave the answer in your question - sort out the "human factors" by providing appropriate training. Version control for software development doesn't get much simpler than SVN, so from the way your question is phrased, my guess would be that said human factors are just going to find other ways of making your life interesting.
if you have issues with your repository getting screwed (like committing on tags, wrong commit messages...), one of the easiest way is to play it the hard way : put hooks on the server to enforce policies. You can have a look in official documentation.
Basically, this is an easy way to enforce naming / formatting and avoid a lot of human issues (committing on tags, messing with externals...)
I work in a Visual Studio/.NET shop which is still using VSS 2005 for source control. We are looking to upgrade to VS Team Foundation Server and use it's source control system, but I'm curious if that's really the best option. The creators of StackOverflow use Subversion but comment that it's a pain to merge code forks back into the main product (discussed in podcast #52). Joel mentioned that Mercurial is used at Fog Creek. Knowing that Joel is something of a software snob and he chose Mercurial over anything from Microsoft, I thought I would pose the quesiton to the StackOverflow audience: which source control product is the best for Visual Studio developers?
We switched from VSS to SVN, using only TortoiseSVN for a long time. Recently we began using the VisualSVN plugin for VS (unfortunately not free).
I must say, after getting over the initial pain of not having source control integration in VS, I really liked the level of control I had over all my source control operations. I highly recommend this route.
If you go with Subversion and must have source control integration, I highly recommend VisualSVN.
If you want to give SVN a try, you can install the very free (and very easy to setup) VisaulSVN Server product and have SVN running in just a few minutes on a Windows server.
My recommendation is for SourceGear Vault. It's close enough to Visual Source(un)Safe to feel "comfortable" with right away, it's rock-solid (built on SQL Server which solves your backup hassles, too), it's very reliable, has great support for branching and merging - all around good stuff.
It's free for teams up to 2 devs and reasonably priced for larger teams - much less $$$ than Team System (also it's only a Source Control, of course - not a whole team dev system). We use it in conjunction with Fogbugz bug and issue tracker and that combo gives up all the bang we need for much less buck.
Highly recommended.
Marc
I've worked with VSS, CVS, SVN, and TFS.
VSS: Skip it. I've lost too many changes that literally have just vanished.
CVS: Great solution. Has one feature SVN is missing with a visual of the merging.
SVN: Great solution. You can get add-ins to integrate if you need them. I have only one complaint: merging between branches could be better. But, the product is bomber and very affordable.
TFS: Where I was working, they didn't do much with it. They only used the source control. I was excited to use it, especially the shelving, but I couldn't merge the changes to a branch. I would say it's pretty much what VSS should be. Sometimes MS tries too hard to do things for you that you just have to do for yourself. Also, the UI isn't intuitive.
So, I'd stick with SVN. Though, the new open source standard seems to be GIT (can't comment on it though).
It seems that you want to have VS integration but I question the reason for that.
A good source control product has many more features than just VS integration.
You can get subversion to integrate with VS ( Ankh svn and visualsvn ) and I've also used vault which is stable and integrated with VS but I use source control for other things other than just vs work.
So I prefer to work with source control out of the product. You should try it.
The source control is only part of VS Team Foundation Server, which is a complete project management system.
I used both SVN and TFS, and both of them are more stable, robust than VSS.
Coming from VSS any system would be an improvement;-)
Perforce is probably the best mainstream tool I have used. Rational Apex was even better, but unless you're writing Ada that information is of no use to you.
ClearCase is pretty powerful, but I found it pretty hard to use (admittedly I only used it for a couple of weeks, so I possibly didn't give it a fair trial).
For the cost (free) SVN is excellent. The Tortoise shell add-in makes it very easy to use in Windows.
EDIT.
I see I just got an upvote from this ancient answer :-) This caused me to revisit and I find I need to update my answer.
I now use TFS at work and I really like it, it's a big beast and not appropriate for home projects perhaps, but it's a commercial tool and worth a look if you really value VS integration. I'm sure Perforce and Clear Case are still great products too, but I am out of touch with those now.
For smaller projects or personal work at home I now use Git. I don't particularly care about VS integration though, I just use it from the command line, but at home I switch between several different environments so VS integration is not a priority.
I've had much luck with Ankhsvn. I'm able to use it interchangeably with TortoiseSVN and it does a great job of tightly integrating itself with Visual Studio and the project layout.
http://ankhsvn.open.collab.net/
We use plasticscm at work, it's less known, but very well integrated into VS, you have all the options and graphs inside vs itself.
+1 to forget about VS integration.
Many of the best source control tools have great command line interfaces. I've been happily using Git for VS projects for almost a year. The downside is that Git requires a bash shell and it is not very Windows friendly. I'm willing to pay the 'cost' of not having VS integration in order to get all the advanced features that make life really easier.
I would suggest giving Mercurial a try.
I have to add that this advice is more suited for a personal choice of source control. If you are looking for a source control standard for a big company with lots of developers, I would go with a more 'standard' choice like Team System, SVN or Vault.
SVN is better and faster than VSS. We switched from VSS to SVN 2 years ago because VSS was on servers in New York and the operations on VSS seemed too slow for developers in India. SVN is faster because it was meant for WAN as opposed to VSS which is for LAN. Refer this link
You can use windows explorer to perform SVN operations or you can use AnkhSVN to be able to perform SVN operations from VS.Net IDE.
You can prefer locking files before editing if you find merging them later to be a hazzle. But IMHO merging is really not tht painful, because you get to see the clear distinction between your and your collegues code before you go ahead with the merge.
Advantages of SVN can be found here on stack overflow.
I prefer TFSVC as it is integrated with all the other services in Team Foundation Server. But it depends on what you want to do. If you want an ALM solution, this is the way to go. I have the ability to set check in policies, integrated builds, and associate with work items. I like the way it does branching and merging. I can have my testers submit bug work items associated with the code in TFSVC. I have traceability to see who is checking in and breaking the builds. I can run reports and get good visibility into the project. Everything works together.
I hope this helps.
John
We use vault, Its good. But use Team System if you can b/c it's from Microsoft. They know how to deal with their own problems/bugs/wayofthinking.
My vote is for TFS. VSS is more than a pain. I have used SVN outside of VS and I would have to see it work along with it.
Working with source control out of the product? Sounds like more work than necessary. Just because it integrates with VS doesn't mean you can't use it for other things. If I am in VS I want to stay in there and not have to go over to another client application to get my source. I like that VS can check out directly.
It depends are you looking free or commercial version control system.
Subversion
Using Subversion you have great, free, open-source ankhsvn plugin which integration Subversion with Visual Studio. Integration is really fantastic!
Mercurial
If you need distributed version control choose Mercurial with VisualHG plugin. Mercurial, in contract to the Git, was developed with native Windows support and also Visual Studio integration is much better.
PlasticSCM
The best Visual Studio integration I have ever seen had PlasticSCM which is the simple consequence that PlasticSCM is windows-background version control system. It works really well.
I can't believe no-one has mentioned Assembla! It's free for unlimited repositories, unlimited users and 1GB of space!
www.assembla.com
Perhaps you should ask yourself what scm is best for your project.
I like svn cause its free and kind of standard(perhaps a little bit bold to say).
I use both Vault and TFS at work. We used VSS and others had issues with it, so the lead at the time decided to switch to Vault. I have had no issues with Vault, but others had some with merge and branch.
I started using TFS Trial and like it as much as Vault. I do not use many of the extras, such as the bug and work item tracking just yet, but plan to.
Since you did not mention cost and the comapny is already looking at moving to TFS, I would think that will satisfy your need of getting a product better then VSS and allow you to grow into it in the future.
I've used Visual Source Safe (2005) and I wouldn't recommend it. Being a file file based solution leads to the risk of your repository being more easily corrupted. I've used Source Off-Site a SourceGear product that enables remote VSS check-in and checkout over the internet and it worked well, but still had the disadvantage that it was built on top of VSS and the flat file architecture.
SourceGear also make Vault which is my preferred solution. It's a SQL Server based repository so it's not subject to issues with the Windows File System. Restores and backups can be configured just like any other SQL Server database and you can restore to a point in time, not just to your last backup date.
I've also used Source Anywhere (version 2.2) and I found it lacking in features compared to VSS and Vault. But it was a SQL Server solution, which made the backups more reliable.
I'm interested in trying Subversion and if there was a version of Subversion that used SQL Server as the repository I think it would be a reasonable solution. If you're running on another operating system, Subversion is probably your best choice, but if you're running on Windows Server I would recommend a SQL Server solution.
I there a Visual SourceSafe server running somewhere that I can connect to for practice? I have a couple of things that I would like to test before buying the VSS server but I don't want to download the whole app for testing.
Best regards
short answer: save your time and don't buy. Use SVN, git or if you are all for an ms solution then use Team Foundation Server.
There are lots of people who love to hate on VSS, and honestly I can't blame them (much). VSS has a reputation for being unstable, corruptable, and idiosyncratic. This reputation, in some cases, is well deserved, in others it's a case of improper management, improper administration, or improper too choice for the job.
VSS is not the tool for everyone, but it is an adequate tool for a large number of people, and it's got very good integration with Visual Studio.
VSS these days is pretty stable, but you don't want to use it over an unstable network (unless you're using the HTTP based server approach) because it can corrupt files. It should only use the file-based version control inside a reliable on-site network. If you're going to do any off-site ore distributed development, then you need to use the HTTP model, or choose a different product.
VSS has some quirks. Branching doesn't work the way most people want it to. This is not necessarily VSS's fault, as it was designed to operate a little different from other Version Control of the time (remember, it's 20 year old product). People that choose it, expecting it to work differently than it's designed to have chosen the wrong tool for the job.
I've successfully used VSS in monster sized repositories. One of the keys is that you need to run the analysis and fix tools on it regularly to head off potential problems before they become corrupting problems.
You also don't want to use VSS in any situation where you need security, because VSS's security is application based. Being that you need direct file read/write access, anyone can go into the files and fiddle with them by hand if they want. Again, this is different if you're using the HTTP server component. (For what it's worth, this is similar to many kinds of version control of that era, such as RCS and SCCS, so it's not like this was unheard of)
Now, having said all this, to answer your question, if you've got download access to VSS (such as through MSDN), just download it.. it's not that big. It's only 100MB.
If you have to implement a source control system. Start with SVN or Git, hands down. Take a look at VisualSvn server with AnkhSvn and TortoiseSvn for client tools. They are all FREE.
Try Accurev (www.accurev.com) or Perforce (www.perforce.com) or PlasticSCM (www.plasticscm.com)
Assuming that I'm starting a new web project at home using Visual Studio, which version control system, viz. Git or Subversion will be better to use? Which one will have the least setup complexity?
Since this is for your own personal playing around, my question is simple: Do you know Subversion or Git already?
If you know SVN - use Git.
If you know Git - use SVN.
If you don't know either - use SVN. It's a better introduction.
I'd go with Git. It's not that bad getting up to speed on the basics (there are now a ton of good resources, including learn.github.com) and it'll pay off in spades. And I've been using it on Vista with no probs.
Subversion is far more Windows-friendly in my experience and also more immediately useful for the solo developer.
Another possibility is Perforce, which is slightly less Windows-friendly, but full featured and fairly easy to use, not to mention free for up to two users.
Git is a distributed source control setup and as you are the only user I can't imagine that you would benefit much from its features. Subversion is (in my opinion) easier to set up so I would recommend you go with it.
If you are working alone and want some kind of version control easy to use, then use Subversion.It works great on Windows, setting up the repository is one right click in an empty with Tortoise SVN. Ankh SVN provides a very good integration with Visual Studio - almost on par with TFS provided you use VS 2005 or more recent.
On the other hand, Git is much more promising than SVN. I'll check it during this year, but third party tools are not on par yet.
I'd go with Mercurial instead. It's supposed to be similar to Git (which I never could get running because of the Windows issue) and is really easy to setup in Windows & very nice for "personal" version control systems.
Which one you decide to use depends a lot on what your needs are now and going forward. Git has a very nice community built a round it with GitHub which is great for sharing code and projects. SVN is pretty simple to setup and get going, but in large teams Git has it beat hands down with it's branching and merging. This is ideal in cases where you have multiple people working on the same project, either in an office setting or an OSS sense where the team is spread out.
If all you need is something quick and simple to setup and get going so you can start your project, SVN should be fine. SVN is also integrated into many editors and IDE's as well as many bug tracking and continuous integration systems.
If you plan on having a team, or already do, Git is worth looking at for its branching and merging setup. Git however, due largely to still being kind of young, doesn't have nearly as much support available
If you want Visual Studio integration there is no question. Only Subversion has Visual Studio integrations (AnkhSVN, VisualSVN and several scripts that allow access to TortoiseSVN).
One of the most important reasons that Subversion has such a large amount of tools written for it is that it was designed as a stable library for use by multiple clients.
It's unlikely that Git gets the same level of integration in Visual Studio before git support is available as some kind of reusable library. (There are plans for a libgit2 that could make this a reality).
Let's my ride-in on your question and ask:
Does Git work on Windows?
Does it have something that's equivalent to Tortoise? (otherwise I don't see how it could compete with SVN in terms of ease-of-use)
On a side note: If it's really a one man home project, you don't really need any source control tool. Just put your project in a DropBox folder and you're done (auto-commits, infinite revisions, undelete).
Unless you really think you're going to need tags and branches and stuff. But for personal home projects... do ya?
You can make your own opinion after reading this : http://whygitisbetterthanx.com
Git................................(these dots are there because SO wont accept a 3 lettered answered).
A great answer to this question was recenting written about by Jack Repenning here:
If you have compelling requirements for a single, certain, master copy of your work, use Subversion. You can do this with Git, so long as there are no slip-ups. But you can’t do anything else with Subversion (slip-ups or no), and “compelling requirements” like Sarbanes-Oxley are happier with guarantees than possibilities.
If you plan to maintain parallel, largely shared but permanently somewhat different lines of the same product, use Git. One common example: perhaps you have a large product that you customize for each customer. The customizations are permanent, and generally not shared among code lines, but most of the code is common to all. Git was designed for just this case (in Git terms, local customizations to the common core, and occasional feature or bug-fix contributions back up-tree)
Neither of those? Take your pick, you should be fine with either tool.*
Full Blog Post here: http://blog.codesion.com/post/15692788883/subversion-or-git-decisions-decisions
With SVN you will have to set up a server, create a repository there, check out the (empty) repository, add your files, and then commit.
With Git, all you need is git init in your project's root directory. Then you can add and commit files as you see fit.
There's not really any idea in setting up a Subversion server, since you're the only one working on the source. Contrary to what many people think, solo projects is a perfect match for distributed version control tools. It's also very easy to grow your project later on.
In my experience, Subversion is easier to "grok", but Git is faster and easier to engage in software development best practices. As a former CVS user, Subversion made immediate sense to me when I started using it. Git took some study and I still have to refer to the manual from time to time, but I love how easy it is to branch and merge code when I've got to maintain a release process.
If you are already familiar with CVS and just need something to keep your history and diffs, Subversion will be easier to get started with. If you are new to version control, the tide is shifting toward DVCS in general and Git in particular, so you may get more mileage out of that in general.
I do recommend you look at a hosted provider so you don't have to worry about setting up a Subversion server or so you can have a backup location for your Git data. You can Google for "subversion hosting" or "git hosting" to see the premier providers in the space.
If you plan to take your project along on an USB stick, use Subversion. Windows XP it really, really, really bad at caching lots of small files on an USB stick. Git writes many small files for commit operations and that takes ages on Windows.
[EDIT] The problem with Windows XP and files on an USB stick is caching (or the lack thereof). To prevent data loss, XP will always write files synchonously on an USB stick (so any write will come back only after the FS has reported that all blocks have been written to the stick). Add that to the fact that USB sticks are slow when handling small files (they have a lot of overhead initializing their wear level management) which leads to very poor performance for any kind of application which writes lots of small files.
[EDIT2] If you put a SVN checkout on the USB stick, you will also have a lot of small files (especially in the .svn directories). So the solution in this case is to put the Subversion repository (the "server") on the USB drive. The repository uses only a bunch of big files (if you use the database option instead of the file based one: svnadmin create --fs-type bdb). This avoids the "many little files problem". There is no way to achieve the same thing with current versions of Git.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
My development team uses source safe at a very basic level. We're moving into some more advanced and extended development cycles and I can't help but think that not using branching and merging in order to manage changes is going to be biting us very soon.
What arguments did you find most useful in order to convince your team to move to a better solution like SVN?
What programs did you use to bridge the functionality gap so that the team wouldn't miss the ide sourcesafe integration?
Or should I just accept sourcesafe and attempt to shoehorn better practices into it?
Reliability
SVN is a lot more reliable with large databases
SVN is still actively supported
Atomic commit - in VSS when you get latest version while another user is performing checkin, you can get an inconsistent state, forcing you to repeat the "Get latest version" in better case, but sometimes when unlucky you may be left with a codebase which compiles but does not work. This cannot happen in SVN thanks to atomic commits.
Features
SVN branch/merge is a lot better
SVN has builtin support for remote access
SVN is more configurable (integration of external Diff/Merge tools)
SVN is more extensible (hooks)
Better productivity
SVN "Update" is a lot faster compared to SS "Get latest version"
SVN command line is a lot easier and cleaner - this is useful for automated build or testing tools
Same level of IDE Integration
VSS had a lot better VS integration until recently, but with AnkhSVN 2.0 this is no longer true.
Open
SVN is open and there is plenty of various tools using SVN or cooperating with it. Some examples include:
integration with many bug tracker or product cycle management products
shell integration
integration into various products
various management and analysis tools
source is available, you can adjust it to your need, fix the problems (or hire someone to do it for you) should the need arise
Cost
You do not have to pay any license or maintenance fees
First, teach them how to use SourceSafe in an efficient way.
If they are smart enough, they will begin to love the advantages of using a version-control system, and if so, they will soon reach the limits of SourceSafe. That's where they will be the more able to listen to your arguments for switching to a better VCS, could it be a CVCS or a DVCS, depending on what's the team is ready to achieve.
If you try to force them to use another VCS when they use SourceSafe in a wrong way, like saving zip file of source code (don't laugh, that's how they were acting in my company two years ago), they will be completly reluctant to any argumentation, as good as it could be.
Find some excuse to start using non-ASCII characters in your C# code (Chinese and Japanese are excellent for this).
SourceSafe doesn't like Unicode (even though Visual Studio does), so if you choose the right Unicode text and check a file in and back out, your entire file will appear as corrupted gibberish. The beauty of this is that because SS uses a "diff" versioning system, this actually corrupts the file all the way back to the original check-in version, and can't be fixed automatically.
When this happens just one time (as it did to me when working on an application that had to support Japanese), you will probably find it to be a decisive argument in favor of dropping SourceSafe.
There were two features that we used to sell management and the team on SVN over VSS.
1) The ability to branch. When using VSS, when a release was scheduled to go out, the entire repository was locked until the release actually went out. This included the test and fix cycle. So, developers were unable to commit anything other than fixes for the release to the VSS repository. This resulted in long integration sessions immediately following each release. With the use of release branches in SVN, there is no longer any need to lock the entire repository.
2) The ability to rollback an entire change at once. Because SVN records all files changed in a single, atomic commit, it is trivial to revert a problematic change. In VSS, a developer had to go through the entire repository and find every file changed at about the same time and revert each change to each file individually. With SVN, this is as trivial as finding the relevant commit and hitting the "Revert Changes from this Commit" button in TortoiseSVN.
As a side note, we use TortoiseSVN and everyone loves the file overlay icons for seeing what has and has not changed.
Whatever you do, move slowly! Don't start talking to them about branching on Day 1 -- it will just put them off. I'm stereotyping VSS users with that comment, but that's what I see out there.
For the developers: sell it as a replacement for VSS that works better and faster. Use VisualSVN on Day 1 so they have a super-shallow learning curve. Sell them on it being the same except faster, more stable, and 2 people can edit the same file and they won't have problems with some guy being off sick with locks on a bunch of files.
For the admins: sell them on it being more stable and easier to administer than VSS. Show them VisualSVN server.
Good luck!
First, document all the problems you are having that can be traced to root causes within the source control system. Keep track of them for a month or so. Add on top of that missed opportunities resulting from not using it. (if you say "opportunity costs of not using subversion" you may impress an MBA-type manager). These numbers are actually an understimate of the opportunity cost because presumably you could have been doing work that provides more than your hourly bill rate of value if you weren't messing around with VSS.
For example, do you have problems where files are locked that need to be accessed by more than one person?
Have you had problems with partial (non-atomic) check-ins?
Do you have problems where it is difficult for you to keep track of releases of the software and recreate the repository as it was in the past?
Do you have problems getting a copy of the code onto a server that doesn't have a sourcesafe client?
Do you have problems automating your build and testing process because continuous integration tools can't monitor your version control systems for updates?
I am sure you can think of many others.
If you can figure out the approximate time/money costs of problems caused by sourcesafe and benefits of things that subversion provides (using a generic number like $100/hr for labor costs or just hours) and any costs of late delivery of projects, do so. If you have collected data for a month or so, you can show the benefit using subversion per month.
Then present the approximate time/cost of moving to subversion. (About 8 hours to setup and migrate code, and 2 hours per developer to connect, checkout and move projects, something like that) The risk is low, since sourcesafe is still there to rollback to.
If the cost is more than the monthly benefit, you can divide the cost by the benefit to figure out the recovery period. You should also total it up over 3 years or so to show the long term benefit. Again, emphasize that the real opportunity cost is not directly calculable because you could have been adding value during the time you were trying to manage non-branched releases in sourcesafe.
Nobody recommends using SourceSafe any more, not even Microsoft. They will now offer you an (expensive) TFS licence instead. SourceSafe is just not reliable.
I wrote about it here: Visual SourceSafe on E2. It's a bit of a rant, but that's because I had to use SourceSafe for quite a while, and the memory makes me froth at the mouth a bit.
Reliablity is the big one that will bite you. But also there are features that you may appreciate in SVN or TFS:
TFS and SVN both have atomic commits of multiple files, but Sourcesafe does not - if you check in two files "at once", it's not one operation, it's the same as checking in one of the files, then checking in the other. You can get at the state in between, where one file has been checked in, but not the other.
SourceSafe does not keep history of deleted files, file moves or renames.
Contrary to initial impressions, SourceSafe does support multiple simultaneous checkouts of the same file, if you set the right options. But TFS and especially SVN are better designed for this way of working
Unlike SourceSafe, TFS and SVN both work fine against servers on the internet (TFS just OK, SVN excellently) and SVN works well offline - e.g. if you have a laptop on a plane or train and no 'net, you can still work and compare to previous revisions or even revert, since the data to do that is held locally.
As someone else pointed out, SourceSafe, like CVS, is a "dead" product. It is not being actively developed. TFS and SVN will have next versions out some time in the future.
First search google for the sheer quantity of pages describing how bad VSS is and share that with your coworkers.
Second, skip subversion and go straight to a proper distributed SCM like git or mercurial. Because merging is such an inherent part of distributed SCMs, they have to handle merges much better than centralized systems like svn. Subversion is still trying to retrofit itself to handle branching better, where the distributed systems were built correctly to begin with.
The AnkhSVN plugin for VS is pretty good. It's got a few oddities but on the whole works well.
Convincing the team to move is hard work - I never managed it :-( Probably one of the more practical arguments though is speed - VSS is s-l-o-w when you've got a 1GB source database and several users.
edit It's been so long since I used VSS I forgot it was locking! Yes, as mentioned here the ability to move to a non-exclusive/merge changes model should help if you've got more than a handful of developers. It saves yelling "Can somebody check in the common includes" across the office!
You say "What arguments did you find most useful in order to convince your team to move to a better solution like SVN?"
If you don't know that it's a better solution, then why are you making the arguments? If your mind is made up enough to go argue for a solution, you should know what those reasons are already.
What convinced you that you should move to something better? Those are your arguments right there. Anything short of those arguments will sound like it's just an issue of personal preference.
TortoiseSvn (free) is really nice for explorer integration, giving you all the features of svn from a context menu.
VisualSvn (commercial) makes it just as easy to integrate svn into Visual Studio, with the same status indication in the solution browser as well as context menus to use all the subversion features.
Both these tools go a long way to making version control seamless. It's been a coupe of years since I dealt with VSS, but these tools are a way nicer way to use source control.
Ditto for what every one has said about VSS being poop
Subversion has good support for branching and doing merges... I don't remember VSS having any capabilities in this department at all. I do remember teams going through pain of week long merges when needing to release from VSS, pain which just doesn't exist anymore with Subversion.
Build some automation that mirrors the VSS repository into a SVN repository
It takes time to build a consensus. If your SVN mirror of the VSS repository is available at all times, it will be easier to accumulate converts. The mirror doesn't have to be perfect- it just has to be usable. There are existing tools for this purpose.
Tell them to treat the source code as if it was money and point them to the numerous examples of SourceSafe coming down in flames taking the source with it. Things like that are just not supposed to happen in a proper source control system.
The best argument against SourceSafe is that it is just isn't Safe, everything else can potentially be called "features we don't need".
The clincher for us was the speed (i.e., the lack thereof) of VSS over VPN and low bandwidth hotel networks on the road and the problems of trying to tunnel through firewalls so that two teams at two different sites could quickly, securely, and reliably work from the same code repository. We were running two VSS repositories and packaging up "deliveries" that had to be merged into the other site's repository to keep them in sync.
The team grumbled for a while, but quickly got over it. TortoiseSVN is fantastic by itself and the AnkhSVN plug-in for Visual Studio really eased everyone into the changeover.
Looking back, I can't believe how many "Can you check in file SoAndSo?" e-mails we sent around, not to mention the "SourceSafe is down. We've got to restore the repository" e-mails.
Sheesh. After reading this comments and writing this response, I can't believe we put up with VSS for as long as we did.
Web page summarising problems with VSS - just point people to that URL
If you use VisualSVN the team won't miss VSS as much. 2 people being able to work on one file at the same time is a big selling point too.
The unreliability of source safe ("please fix the repository...") was enough of a sell for us. Andecdotally (I've never measured it) SVN also always seems faster. Good concurrent checkouts / merging.
I'd always figured that to a developer it was almost too obvious. SourceSafe just seems to break and die all too often to not want to replace it...
Tell them to read this http://www.highprogrammer.com/alan/windev/sourcesafe.html
I would recommend that you go ahead and start introducing best practices to your sourcesafe usage with a view to changing to subversion further down the line. Hopefully this will make your actual subversion migration easier and give you time to sort plan out your development cycles, branching strategies et al. properly.
The other thing to consider is your development process in general. A source control management system is only ever part of the solution, to get the most out of subversion or any other product you will probably want to look at how it's usage interacts with your code review, qa and build processes.
I don't remember any SourceSafe user ever liking the product. Do your colleagues actually like it?
I've got a similar issue with CVS at my current customer's usage. Since "it works" and they are mostly pleased with it, I cannot push them to change. But daily I sure wish they would!
When I was at the launch for VS2005 I managed to corner a Microsofty and ask why SourceSafe was so awful to use. The reply I got was rather shocking, not just because of what he said but because he was so up front about what he'd said.
He told me that it was only really meant for one person to use and even then it wasn't very good at doing that.
My colleagues and I were a bit shocked we couldn't think of much else to do other than laugh out loud, as did the Microsofty! He then told us that it wasn't used internally.
So, we switched to subversion shortly after that. We'd pretty much decided to go for it before the launch event, but that just confirmed we'd made the right decision.
We used to use SourceSafe. Then, when I joined the team I was in a different location and even though we have a fairly good LAN when I tried to check out the latest version it took 40 minutes. I persuaded them to convert to CVS (we now use SVN) and the checkout time dropped to a couple of minutes. SourceSafe was just too slow to be usable at a remote location.
We moved from SourceSafe to Source Gear Vault. This source control engine is very comfortable for some one used to SourceSafe. We finally decided to make the change after a couple SourceSafe corruption incidents, that came at critical times. So my advice would be to focus your sales presentation on SourceSafes unreliability.
Surely using source safe is enough reason to want to migrate to another source control system?
I used SVN and CVS at my old job and have moved to a company that uses Source safe (we are going to migrate to SVN) and just using VSS has been enough for me to take a serious dislike to it. I went in with an open mind, despite many of my colleagues from my previous job telling me horror stories about VSS I assumed that it would have gotten better since they used it.
Not being able to edit a file because somone else is/was editing it is ridiculous. I've tried to move to more distributed versioning systems like Bazzar which is made by cannonical however it's not mature enough in terms of the tools available.
Source safe gets in the way of development where SVN helps you almost every step of the way.
Plus Using tortoise Svn made code reviews a lot easier.
Only to the extend as you are able to herd a bunch of cats. I've been there twice and in both cases it took some serious problems in Source Safe before people saw the light. As a manager on the other hand I simply directed the team to use SVN and our productivity increased by 300% ( this was working with a group in India and in the US. We had code exchanges that used to take a long time before svn )
Also Trac mounts on top of Subversion. It's free and a great way to view the repository (timeline, wiki, etc)
As you're making these arguments, consider whether you need to address any policy your company may have about using open source tools. See this answer to a prior question: Switching source control
Make them use it and they will switch to something else :)
Now, being serious, tell them its not that hard to use it, many developers that I've known refused to switch because they related subversion to unix and wierd commands, show them interfaces like ToirtoiseSVN or VisualSVN, tell them that Subversion allows them to edit the same file withouth a forced locking like VSS does.
And last but not least, it is Open Source. It has lower cost than buying Team Foundation Server and if you look around you will see that small teams of developers work quite well with SVN.
I used SourceSafe on a small development team and was responsible for keeping it running.
I found the database gets corrupted pretty easily, and there isn't much recourse when that happens. The "repair" feature (as with most any Microsoft repair feature) just doesn't work 98% of the time.
Naturally, when our database became corrupt, we tried to restore from our backup archive. That was when we discovered the other bad thing about SourceSafe: its 2GB archive limit. We were making backups at our office for months before we ever realized that they couldn't be restored and were useless.
SourceSafe is just a disaster waiting to happen.
I'm planning on ditching SourceSafe in the next few weeks, after over a decade of putting up with it. Mostly I've been using it within the context of a small (< 5 person) team, and not had to do a lot of branching because there's been no call to do it.
However, the #1 problem for me, and always has been, is that the damn thing is so prone to corruption - if you have your SS database (lol, database; collection of randomly named files more accurately describes it) on a network drive, and something happens to your LAN connection partway through an add/checkin operation - 9 times out of ten you get "invalid handle" and the damn thing is corrupted in some way, and then you get to play Russian Roulette with the Analyzer tool.
I realised, a couple of months back, that for the past decade I had been making local zipped up copies of the source at every release of the software I was working on, because I didn't trust the source control system. What a waste of time.
So, it's going. I'll probably use Subversion and TortoiseSVN, because I think the team will need a UI to ease the transition.