What source control should we use

Question

I am looking for a good source control solution. Here are the requirements:

1. Must have a GUI or have an available GUI plug-in.
2. Must be free.
3. Must work with HTTP.

What source control would you choose?

BACKGROUND

Our .Net development team is part of a large parent company. We're in the process of acquiring VS Team System, however the bureaucracy of a large company moves slowly and it could be months before we have a Team System server up and running. In the meantime, we have a large project that will be outsourced to a vendor in India. In the past, our team's process has been something like this: 1)specify the requirements, 2)let the Indian team create the solution, and 3) receive the solution back from the vendor a month later.

We're looking for a more disciplined approach and Team System is our long term solution, however I'd like to use something right now instead of nothing.

Here are some of my thoughts:

1. Source Safe is a no-go, because of stability issues.
2. Ease of use is more important than advanced features, like branching and I'd really, really want it to use a GUI versus command lines.
3. HTTP access is a must, because the development team will be remote.

Additional Information as a follow up to feedback so far

We need a free solution, not because we can't afford it, but because the company's corporate purchasing policies will delay getting it. Free enables us to install at any time. I suppose that if it were cheap enough, I could pay out of my own pocket, but it would have to be pretty cheap.

Final

Sadly, we did not end up using any of the recommendations. We did finally obtain a TFS license, however we're not expected to have clearance to use the server until next year. In the interim, the offshore team is uploaded zip files onto an ftp server. Ugggghh! Why is it so hard to convince large companies that it's ok to use non-standard solutions (such as GIT) rather than wait months (or years) as they dither on trying to decide whether or not a purchase (in this case TFS) is worth it.

Answer 1

Think about a distributed system: darcs, git, or mercurial. They all have their adherents, but operationally they're much similar. darcs can take a long time to build, because it's written in Haskell, and you end up needing to build Haskell first. Mercurial is python based, easy to hack with and extend. And of course git is what's used for Linux, very widely available, lots of tools.

Subversion is, I think, pretty much the baseline of modern SCM; it would be a good choice too, but it does force you into having a fixed central server; either you, or your Indian collegues, will have to check out and commit over a long pipe.

Answer 2

Have you tried SVN and using TortoiseSVN for the Shell Extension?

Answer 3

I recommend Subversion and TortoiseSVN. Even the documentation for Subversion is free.

Edited to add: I also strongly recommend VisualSVN Server to setup your SVN repository. The setup was a snap and its been so trouble free I had to go look to see what it was called because I haven't had to touch it once since the initial set-up.

Answer 4

Team Foundation Server is quite easy to use and is easy to get started with coming from a source safe background (shares common terminology for commands). However with part of the development being in India, they may be more knowledgeable about Subversion.

If you use Subversion, i would look at VisualSVN. It's fantastic, simple to use, and quick to set up (TFS is a bit complicated to set up). VisualSVN offers an IDE plug-in ($50) and a server counterpart that bootstraps Subversion for windows machines (Free)

Answer 5

I second SVN and TortoiseSVN.

I moved from CVS and WinCVS and I am very happy with this setup.

Answer 6

Check out Subversion: http://subversion.tigris.org/

Has GUI plugin as well VS .NET. http://tortoisesvn.tigris.org/ http://ankhsvn.open.collab.net/

All open source & free.

Answer 7

I would recommend the source control where most of your team members have the most experience or where you have someone on your team who is an expert for.

In my opinion besides the endless "git is better than Subversion is better than CVS"-discussion I don't think the differences between them is what matters.

It's more important to have someone who really knows how to use whichever system you decide to use.

Answer 8

My recomendation is Subversion + TortoiseSVN (for Explorer integration) + AnkhSVN (integration with Visual Studio).

I think you shouldn't use any of the distributet version control systems because after that you will have to get back to centralized one which could be painful.

Answer 9

As mentioned SVN and Tortoise are the way to go.

I'd also get a license for visual SVN (http://www.visualsvn.com/) it's not free but it is really good, it uses Tortoise svn and gives you it's features in the IDE.

Answer 10

Setting up Subversion for .Net development has gotten easier. You could start by installing Visual SVN Server. This will install Subversion Server on a windows machine, will work you through setting up your repository, authentication, etc.

Then for Visual Studio integration with Subversion you can try VisualSVN, it's not free but well worth the license. But if your budget don't allow it, Ankhsvn also works fine, I use it everyday.

Answer 11

I had to make a similar decision several months back. I liked SVN a lot, but the lack of GUI for the administration was a big issue for my team. TFS was ideal, but very expensive.

We decided to meet halfway and license SourceGear Vault. It doesn't meet your requirement of "free," unfortunately. Although I did find its comparison with SVN to be interesting.

Answer 12

Subversion (SVN) is obviously a popular choice. It's also quite commonly used now (Google Code, Sourceforge, etc.) so there should be lots of documentation out there about its use. Git is a good choice too, but the lack of GUI interfaces available makes it not fit your requirements so well.

I'm assuming since you're using .NET you're developing in a Windows environment primarily. Check out VisualSVN products. They make a great (FREE) Server product for actually running a full fledged svn server in a windows environment (it supports SSL, group/user authentication including Active Directory support).

They also offer a Visual Studio plugin, although it is not free (although quite reasonable at $49/developer). AnkhSvn is another Visual Studio client plugin option. It's not quite as great, but it is free.

http://www.visualsvn.com/server/ - Free Windows SVN Server

http://www.visualsvn.com/visualsvn/ - Visual Studio Client Plugin

http://ankhsvn.open.collab.net/ - Free Visual Studio Client Plugin

So, I think Subversion using VisualSVN's product offerings are going to give you the best windows/gui integration at a very reasonable price.

Answer 13

SVN sucks quite badly over HTTP in my experience. You will want to pull your hair out if your repo is of any significant size especially with a Trans-Atlantic round trip stuffed in there. Personally I'd go with Mercurial.

Google has recently done some research on Git versus Mercurial. The largest advantage that Mercurial had was that it played extremely well with HTTP.

TortoiseHg, while not quite as mature as TortoiseSVN, is a pretty solid Windows GUI. Although you mentioned you're not very interested in branching and merging, these are common activities in all DVCS. Fortunately because they are common, they are well supported in the UI and relatively painless activities overall.

Answer 14

If you're certain you're going to Team System, then I believe there's a 180-day trial you can use. That way, you son't have to switch.

Answer 15

Have you tried unfuddle (http://unfuddle.com/). Fulfills all your requirements.

Answer 16

Mercurial is great and really easy.

Answer 17

Another vote for SVN.
For a lightweight SVN server on windows look at sliksvn. It doesn't do http source browsing, but is a much smaller and easier setup than apache based servers for small groups.

Answer 18

Give Mercurial a shot. BitBucket has free accounts you can play around with. I've written more about why I use it here.