I'm a grad student in Electrical Engineering, and my lab has various projects related to ultrasonics. We have lots of code to perform simulations, but right now our situation is such that any given script has ~5 different versions. In addition, one person might develop code to simulate wave propagation, while another needs that code to perform a different simulation. This results in code being emailed back and forth quite a bit.
I suggested version control to my advisor, and she says that she likes it, but doesn't have time to manage a VCS, so it would have to be set up in such a way as to require as little maintenance as possible. Obviously, we're not releasing software to the public, so it doesn't matter if the internal structure is unconventional.
Most of the lab are not professional coders, but we all need to write MATLAB code as well as some other stuff. So, I don't expect the users to be so good about clean commits and the like, so it would be good for everyone to have their own "workplace" or something like that. But to be honest, I've only ever used version control for 3 people at once, so I'm not sure how to set this up.
So I am asking what is the best way to do this. I have only used Subversion, but I wonder if that is the right choice. We need a system that would (sorted by importance, descending):
require little maintenance
be easy to use and learn, since not everyone has used version control
have shell integration (we all use Windows XP)
be easy to set permissions and give everyone their own workspace
be easy to set up and get running
So, (1) What VCS is the best choice, and (2) how should we structure it. Thanks for the help.
We use subversion and love it, for its simplicity, easy of use, integration into the shell environment and the ability to not just version, code, but also specification documents pdf's and other resources we have.
As for structuring it, try and use your logical structure, as close as possible. Keep it simple :)
I see no reason why you should look further from Subversion. Although, for extra little maintenance you could check GitHub (since it is hosted solution, so no worrying about backup, servers etc) but there are hosted Subversion repos as well.
Especially if you're already familiar with it, so you can bring others up to speed and get extra credit :)
Once completely setup subversion should require very little maintenance, it's model is simple to apprehend, it is integrated in the shell, it supports ACLs which work just fine and it's setup is well documented.
you can setup subversion in a webserver, integrate it with a windows domain for auth if needed (otherwise you have to add/remove users, change passwords on the svn server)
You could also go the distributed vcs way, with hosted solutions no server setup, but to get that across your user's mind is gonna be way more difficult than svn. Not to mention getting it across your own head first.
Unless you have complex, fast-paced, parallel development models, I wouldn't recommend dvcs, I would stick to SVN
I agree that subversion is a very good choice.
But you can also consider mercurial: it's easier and it also has a tortoise integrated interface.
I would recommend www.assembla.com. They offer paid subscriptions but for academic projects you can apply for a free pro account.
I have used it for my academic projects and was 100% satisfied by the ease of maintenance, up-time and simplicity
The far easiest way is to use Subversion. But to get it to work the most easiest way (under Windows) you should definitely use TortoiseSVN.
After installation it works right within the explorer is just one right click away from usage. Maybe one of your guys should take a deeper look into the whole documentation to give help if needed. All other guys should take a look into the Daily Usage Guide for a first start.
Also you should take care about how you structure your repository!
Subversion has too many limitations related to the "always online + central server" model.
I would strongly recommend using a distributed version control system.
From the three main ones Git, Mercurial, Bazaar; in my experience Bazaar is by far the easiest one to use and setup.
Related
The company I work for exclusively uses Clearcase. I feel it is not worth the effort to learn and use it as my project would not involve too many people(max of upto 3 people), neither would it involve fancy development flow. How do I convince my manager on using a separate source control for this when they bring up the point of "IT supported and uniform source control through out the company" against my suggestion? Or is that particular point valid and I should go with Clearcase?
Thanks...
PS: I was thinking of using Subversion.
If it's the company standard, then there should be people in the company that know it that can help you get started with it. They should be able to set up your particular IDE to work with it, and make everything as seamless as possible for you. You shouldn't have to learn anything crazy in order to use it - there should be clear instructions.
If there's not, then you're not getting the benefit of "IT supported and uniform source control through out the company" and it makes no difference what you use.
After working through this process, if an argument can be made that there's a better source control that would work better through the firm, you should make it. If it's a company standard, it shouldn't be a pain in the neck to use.
First of all, my condolences.
Is Clearcase that difficult to learn? If yes, I'd consider that a strike against it. If not, you might be better off just going with the flow and learning it.
The 3 people on your team aren't likely to be the ones that maintain the code over its software life, so that argument goes against you as well.
How big is the organization? It's easier for 3 people to learn Clearcase than for X to learn Subversion.
It would depend a lot on your boss and his/her willingness to consider alternatives.
Subversion would certainly be easy to set up and use. I'd hate to be using Clearcase myself.
But there are a lot of factors against you. Good luck.
If I were you then I'd want to use SVN because I just love it but just like anything with developement most of the time you have to go with the flow. Same as if you were extending a framework and you decided to do it your own way completely different to the rest of the framwork it would be frowned upon even if your way was much better. Also what would happen if you and your team got hit by a bus? OK SVN is easy to learn but there is still a learning curve that could slow down other people continuing your work.
You could also view this as a chance to learn a new source control system and make yourself more marketable. You could still prefer subversion, you can't be forced to change your opinion. As #Erick says if this is the company standard they should be able to support you and I'd hope you'd be able to get this factored into your timescales.
There's always the tried & true (albeit risky) approach of having your team use Subversion (how appropriate!) within itself and making the occasional show check-in to Clearcase.
Your argument against Clearcase
are
it is not worth the effort to learn
my project would not involve too many
people neither would it involve
fancy development flow.
Is it difficult to learn? If your company already using it, you will have many people to ask help from. Since your company already have clearcase, you are 80% done with clercase admin works. It will be fairly simple to create vobs, project etc.
In fact your project is small makes it more important to use standard within company. We had some fancy projects done using our standard SCM and some projects without the standard SCM. For the one which used standard SCM, when the projects is scrapped, the code is still safe with in organization. Other products, we lost people and code.
Are you using ClearCase with UCM? It is simpler than base clearcase.
As I mentioned in "Are There Any Reasons To Still Use SVN?", you can't just decide to put a new server on the side, especially for sensitive data like code sources. At some point, they need to be versioned in a central referential.
Any server for that kind of persistent and important data should be:
funded (you can't just manage a VCS on your workstation, you need an actual server)
supported (your jobs is to develop, not to manage /troubleshoot your team in term of SVN operations)
integrated (no problem on that front for SVN)
administrated (again, your job isn't to manage/monitor the SVN server)
documented (where is your SVN server?, what are the backup procedures?, is there any backup/DRP server?, ...)
For all those reasons, your manager might consider leveraging the existing infrastructure/support around the main VCS (ClearCase, condolences ;) ).
But that won't prevent you to manage a DVCS within a ClearCase snapshot view though.
I don't know Clearcase, so I can't say whether it's good or bad or how it compares to Subversion.
But the whole point of source control is that there's supposed to be a single repository where everyone knows they can go to check out their code. If one team uses Clearcase and your team uses Subversion and another uses Git and another uses CVS, etc etc, then anyone wanting to check out source code not only has to look in ten places, but they have to learn to use ten different source code control systems.
Unless you can make a case that Subversion is clearly better than Clearcase in some relevant and important way, I'd say just bite the bullet and learn Clearcase. If it was me, I'd see it as an opportunity to learn something new. After I did, maybe I'd conclude that Clearcase sucks big time and I should try to convince the powers that be to switch to something else. Or maybe I'd conclude that Clearcase was the greatest advance since the invention of USB. Either way, you now know a little more. If nothing else, it's one more bullet to put on your resume the next time you go looking for another job.
Are you working full-time for this company or is this a one-off project as a contractor?
If it's your full-time role as an employee then it's time to buy that "Clearcase for Beginners" book.
If you're looking to deliver a project quickly, then perhaps just keep your head down and use Subversion as an expedient. Ask someone to check the finished article into Clearcase as you run out of the door.
:)
Use a DVCS like Mercurial or Git and make a branch of it to keep synced up with ClearCase. Your team can do the day to day work using a better tool but your organization still has your work products accessible the usual way (which is important). Sync up with ClearCase on a regular basis, and consider adding the output of your systems DVCS log (eg hg log) to a file in the ClearCase branch, so people can see the more granular steps if needed.
DVCS systems are also usually pretty easy to set up, and often can be easily hosted on a network share or something like that. Since all developers will have a copy of the full tree it provides a certain amount of built in backup and redundancy.
This workflow is not uncommon -- gitsvn and hgsvn are both scripts people have set up to let them use those tools by themselves but sync up with folks on another repository.
We are a small Microsoft shop with 4 developers. We like the idea to have everything integrated and under the same SQL database but not to deal with too many features or a complexity we don't need.
The other option would be to use two distinct third party tools. We also wonder if VS2010 version control and bug/issue tracking capabilities are comparable with the best third party tools on the market.
With TFS 2010, there is a TFS Basic version/configuration options. You can use SQL Server Express as the database, the install is simple and quick and you can install it on a client OS. It includes version system, work items and build system (no sharepoint, reporting...). Price should not be high, the target users for TFS Basic are those used to use SourceSafe. Also if you have MSDN, there is a change that it goes with it, so you would not have to pay extra.
Some thoughts on TFVC in general -- note that I've never used TFVC specifically, but I've been in a similar situation a couple times. My main concern is that it's too little.
TFVC (Team Foundation Version Control) appears to be a client-server version control system. I don't know anybody who hasn't upgraded to DVCS yet. I've never used TFVC but I can't imagine what benefits it'd offer to outweigh the architectural disadvantage. (And before you ask: I only use it from my workstation in the office, where the network has never gone down, but I still use its distributed features every day.)
I also work at a small Microsoft shop with 4 developers and we have never once regretted using Mercurial. It's one of the few decisions we made that everybody seems to have loved. It's one of those moves, like switching to a language with GC, that you never want to even think about reversing.
In terms of support, I hope you found some way to get great support from Microsoft. Things will come up with any VCS and it looks like community support is a couple orders of magnitude worse than Hg or Git.
I can't say much about bug trackers -- I think they're all pretty much the same these days. I've installed a couple open-source ones in an afternoon, even with no experience. The major difference seems to be, if you go with a big-name one, you'll be able to find lots of tools and extensions that work with it. For example, there are a million and one extensions for reporting/testing/etc. for Bugzilla. TFS probably has similar things, for enough money.
Two other things I'd keep in mind:
First, even if you only want these 2 features today, you will want other features in the future, and it will be (sooner or later) something Microsoft doesn't offer. So it's best to make peace with 3rd-party tools ASAP.
Second, unless you miraculously happen to pick the perfect set of tools for your company's future growth for all time, you will at some point want to migrate away from whatever solution you pick today. So make sure it either provides a way to do a full export, or is popular enough that other projects are falling over themselves to write importers for it.
I guess this all sounds kind of negative for TFS. I didn't really mean it that way -- I'm sure it does some things really well. But unless you're rolling in dough already, save your money.
Good luck with whatever you choose!
TFS work ittm tracking is awesome. Whatever your workflow is and the information you want to gather, you can do it easily with TFS.
Most expect TFS to do what they do out of the box as if it were omniscient. Unfortunately, you do things slightly differently than me and I from everyone else. The key is making it easy for the many different roles in your organization to get and input information into whatever your work tracking system is.
There is a plateau you will reach with custom, cobbled together tools that you won't get from cross referencing information along the product development process. TFS removes that barrier. The second barrier is knowing how to consume the information and that takes training and experience in effectively managing projects.
TFS Version control is certainly the low point when compared to the industry right now. DVCS popularity exploded about the time TFS came out. That said, Brian Harry has stated that TFS "fully expect that we will be adding distributed version control to TFS." http://blogs.msdn.com/bharry/archive/2010/01/27/codeplex-now-supports-mercurial.aspx
Take that as you will.
TFS is a great system but after having deployed and used it for some time I realize that the TCO is just too high to justify for a small team.
In contrast to most software development organizations, our little research group within a university department consists of a professor and a flow of grad and undergrad students, it's hard to retain any working knowledge beyond the research itself. Our backgrounds vary, and rarely involves much computer science background. (i have not myself ever taken a computer-related class.)
Yet we need to work on our homebrew software for planning and analysis, with distinction between the best current production version and development versions, protection against ill-conceived changes, ability to recall last year's version, etc. It'll be hard to get each student up to speed on subversion and learn to be careful about the repository, understanding branches/tags or however we organize it. (secondary question: how to get someone up to speed on svn?)
Perhaps one of the distributed version control systems would be better suited, or a centralized system other than svn would be wise, or if not, are there easily propagated practices with subversion we should follow?
I'd say that Subversion should give you the right balance between usefulness and easiness in an academic environment like the one you're describing. I've been thinking about similar issues (I'm a physics graduate; I actually posted about something similar before), and my advice at the moment would be:
Set up a centralized version control system, preferably SVN. With grads and undergrads appearing and disappearing all the time, I'd say that distributed version control might well lead to revisions that people are working on "locally" disappearing with them. Centralized version control would give you "One True Revision".
Let everyone experiment with a small test repository, so they can get the hang of it. If you search around SO, you will find plenty of questions & answers referring to good tutorials.
Perhaps consider renting a hosted SVN repository, it might save you the hassle of setting up your own on your local network. (Some universities I know have very strict rules for network security, so getting your own server is sometimes a long and complicated bureaucratic process.)
Tell your students: code does not exist until it's checked in! And I guess they will soon enough discover the advantages of VC, once they have to do their first "revert"/"rollback" :)
As for getting students up to speed with Svn: see the Software Carpentry Course on Version Control and the "Getting started" chapter in the Subversion book. You may also want to have a more experienced person just sit with a new student once or twice (seems like a waste of time, but pays back double!).
Note, though, that I don't have much actual experience with this. So I would be very happy if you could, e.g., post back some time later to tell us about your experiences!
I am not sure that "getting everyone up to speed on SVN" is difficult. If they understand the concept of version control this is one of the simplest implementations to use.
It certainly has a lot going for it, but the others you mention would work as well, though may be harder to get buy in for initially. (ease of use)
I think you'll find the harder thing is to define a policy that you all should use when working with the source repository. Once you define that then you can implement the version control system. (I.E. developers have their own branches and then get promoted to mainline/trunk after testing, or everything goes into trunk, etc)
Even if you never use branching and merging, svn is valuable. If you're on Windows the, VisualSVN server app is easy to set up and makes it easy to use security. Try it out.
Subversion and TortoiseSVN makes using Subversion no more difficult than using Windows Explorer itself. There are a variety of interface for other OSs that make subversion very easy to to use.
What would be the best version control system to learn as a beginner to source control?
Anything but Visual Source Safe; preferably one which supports the concepts of branching and merging. As others have said, Subversion is a great choice, especially with the TortoiseSVN client.
Be sure to check out (pardon the pun) Eric Sink's classic series of Source Control HOWTO articles.
I'd suggest you try Subversion, for example with the 1-click SVN installer. Try searching SO for "Subversion", and you'll find loads of questions with answers that point to good tutorials.
Good luck!
I'd go straight for Git. I've used subversion before, but always felt like I was doing it wrong. Git made sense from day one.
Useful resources:
Linus Torvals on Git
Scott Chacon "Getting Git"
There are a few core concepts that I think are important to learn:
Check-ins/check-outs (obviously)
Local versions vs. server versions
Mapping/Binding a local workspace to a remote store or repository.
Merging your changes back into a file that contains changes from
others.
Branching (what it is, when/why to use it)
Merging changes from a branch back into a main branch or trunk.
Most modern source control systems require some knowledge of the above topics and should help facilitate you learning them. Then you have distributed source control, which I don't have any experience with but is supposed to be fairly complicated and may not be suitable for a beginner.
Subversion is great because it has all of the modern features you'd want and is free.
Git is also becoming an increasingly popular option and is another free or very low cost alternative to Subversion. Knowledge regarding the concepts of branching and merging become critical for using Git, however.
You can use unfuddle as a free and easy way to experiment with both Git and Subversion. I use it to host a couple of subversion repositories for some side projects I've worked on in the past.
I'm not and advanced source control user, but I'm learning. Here is my experience with source control products:
A long time ago, the company I was working for at the time decided to use source control. They introduced the concept to developers and got eveyone willing to give it a try. They chose to use PVCS, and implemented it. Before too long, developers would have to coordinate to lock/unlock modules and objects and we really didn't see much benefit.
A few years later, I was playing around with making an open source project and at the time rubyforge was offering CVS repositories. I tried it out and it was marginally better than PVCS. Granted I was the only one using the repository. I did however become frustrated when I tried to rearrange the structure of my files because I didn't like the way I had initially imported them. It didn't really work out in CVS.
A few years after that I was working on another personal project and my web hosting provider offered easy to setup Subversion (SVN) repositories. It took me a little bit of research to get it up and running correctly, but once I got past the initial learning curve, I liked it.
Not long after that I realized that I liked having source control and that my current job didn't have it. So I evangelized, and after a long period of time, my team implemented Source Safe because we work in Visual Studio and are generally a Microsoft shop. I was eager to use it, but before long I found that I was losing files and that Visual Studio was putting things in the wrong place and that I'd work on a project for a while and then go to export my work to another location and find that it either wouldn't export or would only export some of the projects in a solution. This made me realize that even though I thought I was using a "version control system", the copy of the code that was most secure, robust and complete was my working copy. The exact opposite of what source control is supposed to do.
So last week I was so fed up with Source Safe that I went searching. After looking into a few solutions, I decided to try git. I won't say it's all been roses, since I have again had some learning curve to get it to do what I want it to do, However, I have liked it enough to convert all of my work and personal projects over to it. One of the really nice things about it is that I don't need a centralized repository so I can use it without going through a ton of red tape at work to get it installed.
So in short I would reccommend git, I use Mysysgit in windows and it has the added bonus of giving me a bash shell. On Linux you can just install it from your package manager. If you don't like git, try subversion. If you don't like either of those you probably won't like CVS or PVCS either. Under no circumstances try Source Safe, it's awful.
I found http://unfuddle.com saved me messing about with installing SVN or git. You can get a free account in there and use either of those - plus you can use your OpenID there.
Then you avoid having to mess about setting it up right and focus on how you're going to use it!
Vault from SourceGear.com is superb. It is free for single users and provides a superb VS 2005/2008 interface. I love it!
rp
#Ian Nelson:
I agree with you that Source Safe is bad as a source control system, but keep in mind that using Source Safe is a lot better than "carrying around floppy disks" as Joel Spolsky said.
For a beginner it might not be a bad idea, since the cost of having no source control at all is a lot higher.
Each tool has it's strengths and weaknesses. It's very much a question of what your requirements are. Unfortunately with this issue, like many others, it's often not the best tool that is selected but the one that someone is familiar with. For instance, if you don't require many branches and your team is small and local, almost any vcs will do the job (except SourceSafe). Things change if you need branches (which almost by necessity means you also need to do merges), your team is distributed, you need advanced security (subcontractors are not allowed to entire source tree), task tracking, etc. There is also the question of cost in three different ways: cost of licenses, cost of maintenance (some tools are so complicated that you in practice need someone just to control the repositories) and cost of training.
Therefore suggesting one tool over another is like suggesting what would be the best programming language.
Just some pointers:
StarTeam is the easiest of the tools
I have used. It required very little
training. I got a one-day training
since I was to be the maintainer.
This maintaining took me less than 30
minutes per week. Users I "trained"
by writing a two-page manual and
after that I had very few questions
to answer.
Continuus was the other end of the
scale as far as ease of use is
concerned. On the other hand task handling was great and it offered good support for release management. Trouble is, even as a release manager I never thought ease of making releases (it was once you learned how, but that took a considerable amount of time) should be more important than the daily work that developers do.
Merging and branch creating differs
wildly between tools. Some tools make
this simple, like git and ClearCase
(although the latter is very slow)
some basically force you to do the
merge by hand. If you need to do
merges a lot, the cost can get high.
ClearCase was also expensive in all
three categories mentioned before
(although it has to be said we used
all the advanced stuff which isn't
necessary). Git on the other hand
lacks a good UI and some of concepts
differ from what you might be used
to. Git's security features are also
lacking (gitosis addresses some
issues but not all).
Most tools I have used are also quite
slow. Tools like PVCS/Dimensions was
just slow, no matter what (basic
things like opening a directory in
the repository), some very slow in
more specific ways (like ClearCase).
From the tools I have used I would select StarTeam if your developers are not very experienced (and if you don't mind paying the license, which is quite expensive) and git if you have some experienced vcs guys onboard who can set up the environment to other guys. Mercurial also looks like an interesting competitor and seems to have slightly better UI's.
Continuus, PVCS/Dimensions and ClearCase are just too slow, too complex and too expensive for almost any project. If someone insist on selecting one of these, I would go for ClearCase.
I haven't used Subversion which many seem to like (yet, I have a feeling this is about to change in the near future) so can't comment how it compares to the other tools I have used (usually as a build and/or release manager).
As for the first tool to choose, problem with Git, Bazaar and Mercurial is they are distributed vcs's. This is different from the traditional server-client model where you have a central repository. For just learning the stuff I would recommend also reading about the concepts. Branching for instance is something that you might not understand correctly just by trying yourself (there are different branch strategies for different situations). Plus it is very different if you are the only one accessing the repository, merge conflicts for instance wouldn't be a problem (you might get to see them but you would easily also fix them since you know the code in both branches). Of course you would learn about check outs, check ins, and such but I don't think these issues are particularily difficult in the first place.
Added problem with vcs's is that they tend to use different terms. In StarTeam which is otherwise easy to use they for some reason insist on using the terms "check out" and "check out and lock". The latter is what most people think the first does. There is a reason for this (you can edit files even if you don't have an exclusive lock), but it would still make much more sense to call these "Get" and "Check out" to avoid confusion.
Anything, but I would learn a modern system like git or subversion myself. My first VCS was RCS, but I got the basics down.
Well, if you are just wanting to learn on your own, I would say you should go with something free, like subversion. If you are a company who has never used source control before, then it really depends on your needs.
My first exposure was CVS with WinCVS as a client. it was horrid. Next was Subversion, with TortoiseSVN and Eclipse's integration. It was intuitive, and heavenly. I think that using CVS with TortoiseCVS and Eclipse's would be nice as well, though I prefer the way SVN handles revisioning. The entire repository is versioned with each check in, not individual files.
I'd also recommend Subversion. It does not take too long to set up, it is free, and there is a really good book available online that goes over the basics as well as some advanced topics: http://svnbook.red-bean.com/
Subversion with tortoisesvn. (tortoisesvn because you can see a lot of what goes on visually and will provide a good jumping off point for the command line stuff. ) There is tons of documentation out there and most likely you will see it at least one point in your career. Almost every company I have worked for and interviewed with runs SVN.
If you're looking to learn a commercial product while getting started Perforce provides a free client and server, with the server supporting two users and five client workspaces.
At my previous place of employment it was used religiously not only for code by our programmers, but for art assets and game levels, and my own documentation.
Subversion is good place to start with. It is very stable and modern version control system.
Best online resource to start learning about Subversion would be Version Control with Subversion. There are lot of choices as far as server and client softwares are concerned. I personally prefer (for Windows environment).
VisualSVN server
TortoiseSVN shell-integrated client and
AnkhSVN Visual Studio Subversion Add-On
Again, with Subversion there are lot of options available. Also, it is a continually evolving version control system (unlike outdated SourceSafe). It could be easily integrated with numerous automated build tools (CruiseControl, FinalBuilder) and bug/issue tracking systems (JIRA).
If you are looking for state-of-the-art version control systems, go for Git(developed by Linus Torvalds). But if you are totally new to version control systems, I would suggest start with subversion.
I've been programming for 10+ years now for the same employer and only source code control we've ever used is VSS. (Sorry - That's what they had when I started). There's only ever been a few of us; two right now and we usually work alone, so VSS has worked ok for us. So, I have two questions: 1) Should we switch to something else like subversion, git, TFS, etc what exactly and why (please)? 2) Am I beyond all hope and destined to eternal damnation because VSS has corrupted me (as Jeff says) ?
Wow - thanks for all the great responses!
It sounds like I should clearify a few things. We are a MS shop (Gold parntner) and we mostly do VB, ASP.NET, SQL Server, sharepoint & Biztalk work. I have CS degree so I've done x86 assembly C, C++ on DEC Unix and Slackware Linux in a "time out of mind" ...
My concern with VSS is that now I'm working over a VPN a lot more and VSS's performance sux and I'm afraid that our 10+ y/o version 5 VSS database is going to get hoosed...
There's the LAN service that's supposed to speed things up, but Ive never used it and I'm not sure it helps with corruption - has anyone used the VSS LAN service? (new with VSS 2005)
I'd probably go with Subversion, if I were you. I'm a total Git fanatic at this point, but Subversion certainly has some advantages:
simplicity
abundance of interoperable tools
active and supportive community
portable
Has really nice Windows shell integration
integrates with visual studio (I think - but surely through a third party)
Git has many, many other advantages, but the above tend to be the ones people care about when asking general questions like the above.
Edit: the company I now work for is using VisualSVN server, which is free. It makes setting up a Subversion repository on a Windows server stupid simple, and on the client we're using TortoiseSVN (for shell integration) and AnkhSVN for Visual Studio support. It's quite good, and should be fairly easy for even VSS users to pick up.
Latter-day Edit: So....nearly eight years later, I would never recommend Subversion to anyone for any reason. I don't really recant, per se, because I think my advice was valid at the time. However, in 2016, Subversion retains almost none of the advantages it used to have over Git. The tooling for Git is superior to (and much more diverse) what it once was, and in particular, there's GitHub and other good Git hosting providers (BitBucket, Beanstalk, Visual Studio Online, just off the top of my head). Visual Studio now has Git support out-of-the-box, and it's actually pretty good. There are even PowerShell modules to give a more native Windows experience to denizens of the console. Git is even easier to set up and use than Subversion and doesn't require a server component. Git has become as ubiquitous as any single tool can be, and you really would only be cheating yourself to not use it (unless you just really want to use something not-Git). Don't misunderstand - this isn't me hating on Subversion, but rather me recognizing that it's a tool from another time, rather like a straight razor for shaving.
Looks like SubVersion is the winner here. I'd do yourself a favor and use VisualSVN Server. It's free and will save you a bunch of installation headaches.
If you're used to the way VSS works, check out (no pun intended) Sourcegear's vault. It's an excellent way to migrate away from VSS as it comes with IDE integration and supports check out / check in, but when you're ready and feel comfortable you can also move to the edit update commit style of programming found in SVN.
It's free for single developers, runs on IIS and is built on .net so it should be a fairly familiar stack for you to switch to.
Whatever you do, don't change for the sake of changing.
If it's working for you and you're not having problems with it, I don't see any reason to switch.
For what it's worth, Perforce is a potential option if you truly stick to 1 or 2 users. Current perforce docs says you have have 2 users and 5 clients without having to start purchasing licenses.
You might have reasons to switch to perforce depending on your workflow and if you have need of branching the way perforce does it. Not being overly familar with some the other products mentioned here, I can't tell you how perforce compares in the feature department for things like branching, etc.
It is speedy, and it's been rock solid for us (300+ developers on a 10+ year old codebase). We store several T of info and it's been quite responsive. With a small number of users, I doubt that you'd experience many performance troubles assuming you had good hardware for your server.
Having used VSS before, I believe that you can get so many benefits out of a better SCM system that switching should be considered regardless of whether you have corruption or not. Branching alone might be worth it for you. A true client/server model, better interfaces (programmatically and command line) are a couple of other things that could really help just improve your workflow and help somewhat with productivity.
In summary, my view of Perforce is:
It's fast and quite reliable
Plenty of cross platform client tools (windows, unix, mac, etc)
it's free for 2 users and 5 clients
Integrates into developer studio (and other tools)
Has a powerful branching system (that might or might not be right for you).
Has several scriptable interfaces (python, perl, ruby, C++)
Certainly YMMV -- I only offer this alternative up as something that might be worthwhile looking into.
I've recently started using Mercurial for some of my work. It's a distributed system like Git but seems easier to use and seems far better supported on Windows, the latter of which was crucial for me.
With distributed source code control every user has a complete local copy of the repository. If you're the only person working on a project, as you say you often are, this can simplify things a lot since you just create your own repository and do all your commits etc. locally. If you want to bring on other developers later you can just push the full contents of your repository - current versions and all history - to another system, either on a shared server or directly on to another users' workstation.
If you're working only with a local repository remember you'll need a also backup solution as there isn't a copy of all your code on a shared server.
I think that Mercurial has lots of other advantages over Subversion, but it does have a big downside which has already been mentioned as a plus point of Subversion: there a lots of third party tools and integrations for Subversion. As Mercurial hasn't been around nearly as ong the choice is much less. On Windows it seems that you either have to use the command line (my choice) or the TortoiseHg Windows Explorer integration.
VSS is horrible. I may be channelling Spolsky (not sure if he's said this), but using VSS is actually worse than not using source control at all. Despite its name, it isn't safe. It creates the illusion of safety without providing it.
Without VSS, you'd probably be making regular backups of your code. With VSS, you'll think, "Mehh, it's already under source control. Why bother backing up?" Great until it corrupts your entire codebase and you lose everything. (This, incidentally, happened at a company I worked at.)
Get rid of VSS as soon as you can and switch to a real source control solution.
Don't worry about VSS corrupting you, worry about VSS corrupting your data. It does not have a good track record in that department.
Back up frequently if you do not switch to a different version control system. Backups should be happening daily even with other SCMs, but it's doubly important with VSS.
I like using Subversion for my personal projects. I could go down the list of features and pretend like it brings a lot to the table that other source control systems don't, but there's tons of good ones out there and the right choices is really a matter of style. If you check in after each small change (i.e. one checkin per function change), then many people can work on the same source file with very low risk of merge conflicts in practically anything but VSS (I haven't used VSS in years but from what I remember only one person at a time can work on a file.) If this isn't ever going to happen to you, I feel like the best course of action is to use what you know. VSS is better than no source control at all, but it feels restrictive to me these days.
I don't think you're beyond hope because you're asking if it would be better to switch; you're beyond hope when the answer is obvious and you ignore the evidence.
Even if you don't change source control systems, you ought to pick one like SVN or git and spend a few weeks reading about it and making a small project using it; it always helps to sharpen the saw.
I don't agree with the people that say that if you don't have problems you'd better not switch.
I think that SCM is some of the disciplines a good developer should know well, and frankly, even if you master VSS you are just experimenting a small fraction of the advantages a good SCM tool and SCM strategy can do for you and for your team.
Obviously evaluate and test the alternatives first in a non-production environment.
At work we use subversion with TortoiseSVN - works very nicely but it is philosophically different to VSS (not really a problem if there's just you but worth being aware of). I really like the fact that the whole repository has a revision number.
Given a free choice I'd've probably gone with vault but at the time I had zero budget.
I'm looking at things for personal use. There are reasons to use subversion and reasons to use something completely different. The alternatives I'm considering are Vault (as before, free for single use) and Bazaar. GIT I've had to dismiss as I am, unashamedly, a Windows person and right now GIT just isn't.
The distributed nature of GIT and the option of private/temporary checkins (assuming I've understood what I've read) is attractive - hence my looking at Bazaar.
Update: I did some more digging and playing and I actually went for Mercurial for personal use, integrated install with TortoiseHg makes things very simple and it seems to be well regarded. I'm still trying to work out how to force an automagic mirror of commits to a server and there appear to be some minor limitations to the ignore function but its doing the job nicely so far...
Murph
I'd say stick with what works for you. Unless you are having issues with VSS, why switch? Subversion is swell, though a little sticky to begin using it. TFS is far better than VSS, though it is fairly expensive for such a small team. I have not used git so I can't really speak to it.
i used vss for years until switching to svn about two years ago. my biggest complaints about vss were the poor network performance (that problem may be solved now) and the pessimistic locking of files. svn solved both those, is easy to set up (i use collabnet server and tortoisesvn client, although there are two good visual studio plugins: visualsvn - commercial, and ankhsvn - open source), easy to use and administer, and well documented.
it's tempting to say "if it's not broken then don't fix it" but you would get to learn a more modern source control tool and, perhaps more importantly, new ways of using source control (e.g. more frequent branching and merging) that the new tool would support.
If you only have 2 people, and you mostly work independantly, git is going to give you a lot more flexibility, power, and be far and away the fastest to work with.
It is however a pain in the backside to use. Using VSS you're obviously programming for windows - if you're doing Win32 API stuff in C then git will be a learning curve but will be quite interesting.
If the depths of your knowledge however only extend to ASP and Visual Basic, just use subversion. Walk before you can run.
** I'm not trying to say if you only know VB you're dumb or anything like that, but that git can be very finicky and picky to use (if you've used the WinAPI in C you know all about picky and finicky), and you may want a more gradual introduction to SCM than git provides
If you are a one man show and strictly a Microsoft shop, then SourceGear Vault is definitely a prime candidate for switching too.
Features:
Free for Single User, great for you
It uses SQL Server for it's backend, therefore data reliability is huge
It has atomic check-ins, all files checked-in at the same time are arranged in a group and are called a changeset.
VisualStudio integration.
Has a tool for importing from SourceSafe, therefore you can keep your history
The client communicates with the server over HTTP, therefore accessing the source outside the office remotely can be setup very easily and performs well, because they only transfer the deltas of the changes being submitted and received. You can use SSL to secure the connection.
I would definately consider this as an option.
If you want a full Life Cycle in one package then you probably want want to look at Visual Studio Team System. It does require a server, but you can get a "Action Pack" from MS that includes all the licencies that you need for "Team Foundation Server Workgroup Edition" from the Partner centre.
With this you will get Bug, Risk and Issue tracking as well as many other features :)
Source Control
Work Item Tracking (Requirements, Bugs, Issues, Risks and Tasks)
Reporting on your project data (Work Item Tracking, Build, Checkins and more in one qube)
Code Analysis
Unit Testing
Load Testing
Performance Analysis
Automated Build