What source control do I need for a large project in an average company? [closed]

Question

I know Git is great for open source projects. But I was wondering: for a company with 20 programmers working on a 1 year project, which source control system is desirable? From what I heard Git uses pulling; wouldn't it be less than desirable to need to go through someone else to get your changes in the main trunk? Especially when everyone is working at the same time?

That's just of an example I was wondering about. I know how to use SVN but even at my last job we didn't use it on our projects, since everything was done in PHP and those were typically standalone 1 week projects. I just had SVN for my local code and didn't need to use it with others.

So what are good source controls, and specifically why is it good for this?

Answer 1

Use whatever your team is comfortable with. All Version Control systems do roughly the same thing in similar ways; there's no reason to re-invent the wheel because "it might work better". If your team isn't comfortable with anything, then pick the option that has the easiest integration with your team's standard IDE.

Answer 2

Mercurial is excellent, distributed, and free.

Answer 3

I think that it depends on what level of support you need.

I use git at home for my fun projects when having a problem costs me time, but I can spend the time learning what I need to fix it.

At work we use Perforce because having 24/7 tech support is imperative. We have people working on the code in New York, Germany, Ireland, and Japan all the time. If there is a problem we have to get an answer ASAP. In my experience the people at Perforce really know what they are doing and are receptive to suggestions.

Answer 4

While I think that this question is broad and should be addresses on a per-company basis, based on your IT framework and network/development structures, I think that the most important aspect of choosing source/version control is not which application you use, but whether it's use is practically structured and enforced.

Structure and enforcement of usage are the most important aspects of version control.

Plan ahead and get everyone on board. Enforce usage. Not just with programmers, but with everything related to projects (documents, images, etc.).

SVN is a fine application, and can be integrated with many add-ons (including bug/task tracking), doesn't need a separate server and is free!

There are other good source control applications also, as @EricBoersma said:

Use whatever your team is comfortable with.

Just have processes and best practices in place, and buy off from those that can enforce it.

Answer 5

You have some big misconceptions about how git works. Sending a pull request to a gatekeeper is only one way to do it. There are many other ways to set it up, including pretty much exactly like svn, which is exactly how many people start out before they get comfortable enough to customize. With a DVCS like git, you have enough options to structure your source control around your workflow, rather than the other way around.

Answer 6

I used to have the view that source control was just a tool, and that each of the products did more or less the same thing. And then the point of these distributed version control systems clicked with me.

Distributed version control allows you to have more than one central repository. Imagine code changes migrating from the local developer repository, to the feature repository, to the product repository, into the QA repository and finally into the released repository.

Personally I use a commercial product called Kiln, that's based on Hg, but the key feature is distributed version control. It revolutionises the flow of new code from developer into a released product.

Answer 7

You know how to use SVN, then use SVN - only migrate to a DVCS if there's something in them that you need.

What is really important is that you use something that you will like using, that is easy to use. Martin Fowler did a quick n simple survey about VCSs, the results are very interesting.

Answer 8

I set up git at my last job where we were working on a similarly sized project (15 developers, 18 month project) and it worked well.

The way we set it up was:

We had a git server that was our centralized authoritative git server. Team members were discouraged from pulling from each other directly so that all changes went into the central server.

We used the master branch as the main production branch, with tags for each release. Each module in the project was a git submodule. Each submodule had branches for each team member. A maintainer (usually the original author) was assigned to each submodule, and they were responsible for handling pull requests from other team members, and for issuing pull requests to the team lead who would update the submodule in the main branch when it was ready to be integrated into the production branch. We used tags to identify commits that completed a specific feature, or which corresponded to a release.

Answer 9

I'd give Team Foundation System (TFS) from Microsoft at least a good look. I take it from your comments that you are not a Microsoft shop. However, my understanding is, is that there is a fairly robust Eclipse plug in if you use that IDE for development.

The merging and branching mechanisms work as good as any of the other source control systems (better than svn, in my experience, and about as good as perforce), but what really shines is the project tracking and project management aspects of the product, and the built in automation for builds and deployments.

If you are writing a web based application, take a look at the automated UI testing framework, and the load testing framework that you can build and configure in fairly short order. One sleek feature : simulating mobile browsers built into to the load testing.