Switching from Sourcesafe - What to look for in a product

Question

We're looking to move off of sourcesafe and on to a more robust source control system for our .Net apps. We're also looking for scripted/automated deployments.

I'm a .Net developer (web and winforms). However, most of our development staff is RPG for the IBM iSeries and the devs use Aldon's LMI for source control and deployment. Our manager would prefer to stick with Aldon so all of our products are in the same system. However, I don't have experience with Aldon's products on the .Net side. I've used TFS and Subversion with Tortoise a bit, but not enough to recommend one or the other, especially in comparison to Aldon's product.

Does anybody have experience with Aldon's products? If so, thoughts please? Also, other than the obvious things source control systems do, are there things I should avoid or are there must haves? I'm open to any system.

A bit of background, I'm the only .Net dev in our company but I let operations do the deployments. I do want the ability to support concurrent checkouts if we hire a new dev.

Answer 1

You could check my old SO question: http://stackoverflow.com/questions/694596/source-control-for-a-net-guy

Answer 2

My recommendation is to not choose a revision control product based on a particular language/platform you are developing with right now. Two reasons:

1 - that language may/will change in the future, making your choice irrelevant
2 - most shops use more than one language (a different language for scripting if nothing else), so choosing based on one language/platform is short-sighted. Having said that, you DO need to evaluate the client tools available for a candidate revision control system, and see if they will fit reasonably within your current development paradigm.

Better to ask yourself some questions:

• How capable are the administrators? Does the product need to be brain-dead easy to manage?
• How capable are the users? Do they have the experience and time to deal with something like Git with its substantial learning curve, or do they need the simplest product going?
• Do you need distributed revision control? (The answer is often "yes!" as soon as you realize the power it gives you.)
• What build/continuous integration system are you interfacing with?
• What security model do you want/need to use?

Answer 3

Check out Joel's post: Distributed Version Control is here to stay, baby. Great food for thought if nothing else

Answer 4

We use SVN for our source control, AnkhSVN for VisualStudio, SublimeSVN to manage the repository backups and users and finally CuriseControl.Net for scripted/automated deployments.

Answer 5

The features you need depend on what your requirements are. I don't have a lot of experience with SVN (although I have used it and like it), so I will concentrate my comments on the centralized systems. (I do know a lot of developers who swear by the distributed systems, however). The questions you should ask yourself are:

1. How many developers are going to be using my system?
2. How much budget per seat do I have?
3. How many different projects will be held in the system and how complex will they be?
4. How will my system be administered (developer startup, permissions, backup)?
5. Do I need collaboration in addition to source control?

These basic questions should push you in one direction or another. If you are going to only have a couple of developers with one or two simple projects and have a small budget, something like Perforce -- it's cheap ($400 a seat, two free last time I checked), has great admin. tools and great branching and merging capability.

If you are going to have more developers and really want to get into the collaboration aspect of things, look at TFS2K10 (I would not go with 2008 if you can avoid it). TFS adds the collaboration element (document storage and versioning) and the project management element (task management, reports, etc.). It's more expensive and more heavy weight than Perforce, but it offers a bit more.