Best source control for us to use(and how to convince people of it?)

Question

Hi, I'm in a little bitty startup company. Right now we are using JEDI VCS for our source control needs, which isn't too bad except for it's buggy. It worked because we were using it to manage "old" Delphi projects.

Now, we are developing things in VS 2008 and .NET and I realized JEDI is extremely tied to Delphi when I went to try to branch a project and an Delphi project file must be provided.

Now then. I'm thinking SVN sounds pretty good, but I've been using it for about 3 years now and am comfortable with it, so I don't want to choose it just because I know it.

My boss wants Sourcesafe. After reading all the "Why to never use VSS" stuff on the internet I just think it looks hellish to develop with, and still will not fix the current problem we are at which is branching(since VSS is hell for branching). He wants for us to use VSS though because it can do source control on SQL databases(apparently? I've never been able to get it to work though and heard it required some separate web develop edition or something.

Now then, what source control should we use(it's less than 5 programmers) that is modern and cheap/free? And how can I convince my boss either that it can't do SQL versioning, or that it's not worth it?

Answer 1

in my opinion for small scale and ease of use, svn is your best bet. There are great ui tools for it, and it works well.

HOWEVER:

If you are willing to do a little learning, distributed version control is quickly becoming a tool of choice for developers.

Even if you are not developing in a distributed environment, the design of distributed source control systems is a natural fit for individuals working alone and for individuals collaborating.

Most distributed version control systems also handle merging and branching much better than svn, because those operations are so fundamental to distributed version control, but the net effect is it's better for everyone.

I'd recommend git (msysGit on windows), mercurial (TortoiseHg makes a great explorer addin), and Fossil as an awesome lightweight alternative.

Answer 2

Since you have used SVN for 3 years don't you think that you have enough data to convince your manager to use SVN? Get details about VSS here and show him the comparison.

Answer 3

Subversion, used it for >5 years. Add in the TortoiseSVN front end and it's pretty damn good.

VSS is rubbish. It locks files on checkout (which I hate personally), it isn't free. You need a separate GUI. It is truly awful across any sort of slow bandwidth pipe. Disclaimer: My experiences with VSS are over 5 years old.

On branching/merging some people recommend git, used by the linux team, not used it myself so can't comment.

Answer 4

I won't weigh in on the choice of VCS, but what we did for SQL version control was to do automated scripting of all database objects three times a day and then check that in. You can script to separate files per DB, or separate files per object or whatever. The database changes in development were not always tied to a specific feature branch - they are usually driven from a separate development DBA perspective working with multiple developer's needs, and typically aren't ever going to be rolled back or merged or whatever.

We also did this for production servers, although production changes usually consisted of performance tweaks and parameter changes to administrative tasks.

We used the command-line Apex SQL Script - it actually supports some VCS systems.

Team System for DB professionals (so-called data dude) supports a sophisticated DB versioning/deployment system, and of course, it also includes complete version control like the rest of Team System. It is also my understanding that the 2010 version is supposed to have a SourceSafe-pricing-level product - not sure whether that SKU will contain any database functionality.

Answer 5

• Avoid using VSS at any cost (I've used it for 4 years). It is old and unsupported (this is usually a magic phrase for managers ;)). It's repos are prone to errors. It is bad-bad-bad.

• SVN is nice and tried. There's a lot of documentation and tools for it (including free Visual Studio integration).

• Current trend is to use distributed VCS, such as Mercurial and Git. Idea is to provide each developer with its own repo which he can commmit with main repo where developers later 'push' their changes. Mercurial has good windows tools (including free VS plugin), git has worse one AFAIK, but it will surely change.

All of them don't store DB scheme automatically, but this can be forced in your development process by saving your scheme in a file and committing it to repo.

Answer 6

One important question that must be asked in a commercial setting is, "who will support us if we get stuck / something goes haywire / etc.?". Most of the open source VCS are widely used by many organizations, both commercial and non-, and have a wealth of free (and paid) resources available to help you. Books, websites, consultants, etc. You also have the source, if you want to dig deeply on your own. There are lots of third party tools that extend the functionality of them, like code review and defect tracking systems. Some commercial VCS (particularly Perforce) also have widespread use, and have decent support, if you want to stick with a commercial solution.

Anecdotally, I've heard more horror stories about VSS than all other VCSs combined. That's not out of pure Microsoft hatred, either.

Depending on your shop's development practice, you probably can't go wrong with one of the "big three": Subversion, Mercurial, and git.

Answer 7

Git, Mercurial and Bazaar come highly recommended.

Mercurial is basically Git with some small implementation changes, and a pure python implementation, which means you can closely tie in mercurial with scripts.

Why I choose mercurial above git for our workplace is because it's a lot simpler for a new person to pick up. One command.

I haven't used Bazaar myself, but I read it's very nice.

If you're considering SVN because "I don't need the distributed part": the modern VCSes are not only distributed, but much much more elegant in functionality. They are thought out properly.

SVN has a lot of issues in it's implementation, including the messy .svn subfolders in every project's folder, so basically if you just mv folder1 folder2, you're fucked with SVN.

If you're not too used to the unix way, I'd highly recommend Mercurial, it's very easy to pick up.

BTW don't take my word for it, have a look at this talk: http://www.youtube.com/watch?v=4XpnKHJAok8

Answer 8

In answer to your boss' belief that svn is not as good because your can't source control the database, our database objects are all in source control becasue we allow no one to to anything to the db except through scripts. Since devs don't have prod rights, they follow this rule or their stuff can't be deployed.

Answer 9

Ok, He's decided I can try whatever I want to. If it works decently, then he doesn't have a problem with it now that I got the database backups going. So I think I'll try subversion simply because it'll be a breeze to get running..

Answer 10

I'd look into Team Foundation Server if:

• You do .Net development
• You have a Windows infrastructure
• You want to manage your development processes with this system.

Of course, it works with Visual Studio and the cost can be steep upfront. If you are in the US and doing WebDev, you can get a 3 years free headstart with the WebSpark incentive program. As an added bonus it integrates well with TeamCity and Cruise Control. Work items can be tied to your artifacts and integrated with MS Project.
It might be a big product for a startup but I suggest you look for the benefits it brings in the process management area if you intend to use them in the near future.

Answer 11

My argument would be to start with SVN. It's not like it has to be a lifetime commitment since it's free--if it really doesn't suite your needs just switch.

You are more likely to find people familiar with SVN these days and almost anyone is able to manage it.

I've had teammates bitch about EVERY version control system. I hear less about SVN than the others. I hear MORE bitching about the big old ones like VSS and P4.

I've used just about all of them, and I've never had a real complaint about svn. Small projects, large projects--it even scales directly to a distributed version control system.