Many people think that Git MUST be better because Linus Tolvards uses it. But, that's mainly because of the way the Linux project operates.
I've had developers tell me how much better Git is when they work with on their own one-man projects because Git is "distributed". They don't realize that Git isn't distributed unless you actually have two copies of the repository. Git uses a distributed repository which can have its advantages. However, there are times I'd rather have a centralized repository like Subversion has. Distributed repository version control systems are good when you have lots of people working on a project, no desire to try to control access to all of those people, and no real deadlines. Think of a distributed repository as a tree with the top level being the "official" archive. At each node of the tree is a duplicate repository. You can check out from any node of the repository and create your own node. Since you have your own node, you have a complete source repository, and can check in and out of that repository to your hearts content. And, you can have your friends share your repository or make their own nodes and treat your repository as their parent repository. The trick is when you want your changes to be placed into the official project. You can submit your changes (in Git as a patch) to the parent repository, but the person in charge of that repository acts as a gatekeeper and can simply reject your changes. Thus, although you still have your changes, and their checked into your version of the repository, they won't be in the parent, and they won't be in the project. You can see how this works out great with Linux which has hundreds of programmers doing active development. Tolvards only has to trust a handful of people. You can check out from Tolvard's master repository, but he won't ever accept your changes. If you want your changes into the official Linux kernel, you have to find someone who trusts you in the hierarchy and use their repository node. However, distributed repository systems don't work so well with most commercial development. In commercial development, you have deadlines and allowing people to work isolated from the rest of the group usually is asking for trouble. Developers simply like working isolated because they don't have to worry about what other people are doing. They can concentrate on their own work. What happens is that developers deliver patches around deadline times because their work is incomplete. Then, someone has to do the merging of all of those changes, and handle merge conflicts. Hilarity ensues. Distributed systems also mean duplicated copy of proprietary information. Your entire source development tree can easily be duplicated far and wide. And, it does happen. Centralized repositories mean centralized control over who gets to see what and who gets to make changes. So, the question is really what are you planning on developing. Is this a corporate development? Will these people have access to the centralized repository, or will it be mainly "off line". Are you responsible for securing the projects or is each group going to do that themselves? If all you're providing is a server, and you have no care about the individual projects, Git might be better. In that case, you have a single person be the team leader for a particular project, and you'll only accept patches from that one person for that one project. If another person wants to work on that project, they'll have to get their copy of the repository from that team lead and submit their changes to that team lead. It keeps you out of the picture. If you have some sort of central responsibility for the various projects, and you're expected to maintain the accessibility, you'll need a centralize repository system like Subversion. -- David Weintraub qazw...@gmail.com