Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I know git is great for open source projects. But i was wondering. For a company with 20 programmers on a 1 year project which source control is desirable? From what i heard GIT uses pulling, wouldnt it be less then 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?

Thats just of an example i wonder. I know how to use svn but even at my last job we didnt use it on our projects since everything was done in php and typically standalone 1 week projects. I just had svn for my local code and didnt need to use it with others.

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

share|improve this question
12  
Because you code in php is not a reason to not use VCS. –  Chris Nov 19 '10 at 16:15
    
@Chris: If it was up to me there would a repo on the network. But unfortunately that company didnt use it at all. I was just saying i had no 'team' experience with source control –  acidzombie24 Nov 19 '10 at 16:23
    
Take a look at programmers.stackexchange.com/questions/940/… –  ysolik Nov 19 '10 at 16:24
    
Or this one programmers.stackexchange.com/questions/19771/… –  Amir Rezaei Nov 19 '10 at 20:01
add comment

9 Answers

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.

share|improve this answer
1  
That's a smart and non-partisan answer - I like. –  Murph Nov 19 '10 at 16:36
    
+1 for pragmatism. –  Jas Nov 19 '10 at 18:08
1  
+1 source control systems are complex enough, anything you can do to minimize this will be for the better! –  Dal Nov 19 '10 at 18:26
3  
There's things distributed VCSs do much better than centralized ones, and you can always use a DVCS as a centralized one, so for long-term general-purpose use I'd recommend Git or Mercurial. For situations like this, any reasonably modern VCS will do nicely, and Subversion is likely the easiest to learn. –  David Thornley Nov 19 '10 at 18:33
    
Definitely use whatever your team knows or is comfortable using. (Unless it's CVS or RCS.) If you switch to something new and everyone has to learn it, do the math: 20 people * 3 hours training * $40/hour = $2,400. –  Barry Brown Nov 19 '10 at 18:44
show 3 more comments

Mercurial is excellent, distributed, and free.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
1  
+1: Perforce is pricey but you get what you pay for. –  rmx Nov 19 '10 at 23:53
add comment

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.

share|improve this answer
    
That's a whole lot of repositories for one project. What a nightmare for merging. –  JBRWilkinson Nov 21 '10 at 22:08
2  
I would agree with you if it was merging with SubVersion or CVS. The reason why these distributed version control products work is because they make merging simple and largely conflict free. –  Ptolemy Nov 21 '10 at 23:02
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
Speaking as someone who has used TFS from Eclipse. No it is horrible. (i can go into details), I would definitly not call it robust. TFS is great, but the Eclipse extension is shockingly bad (Where as AnhkSVN for Visual Studio is great) –  Oxinabox Feb 9 '12 at 13:06
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.