git vs Subversion - pros and cons [closed]

Solution 1:

Are you trying to compare the two tools from a system admin's perceptive or as a programmer? If you are looking at this from a programmers perspective perhaps you should ask this on stackoverflow. Or even better, perhaps you should look at what is already been asked about "git svn".

• https://stackoverflow.com/questions/871/why-is-git-better-than-subversion
• https://stackoverflow.com/questions/161541/svn-vs-git
• https://stackoverflow.com/questions/536779/git-or-svn-for-rails-app
• https://stackoverflow.com/questions/1239577/git-and-svn-on-windows
• https://stackoverflow.com/questions/1310572/what-are-pros-and-cons-of-using-git-svn

The thing about git and svn, is that it isn't an either/or proposition. You can run a SVN repository, and your developers can use git-svn to interact with it if they think git is a better tool in a particular case.

Solution 2:

There aren't really any pros to subversion over git, really. While git is distributed, everyone can work off of a central repository using remote tracking branches. git is faster, more flexible, and merging actually works. Plus, you can realistically work offline whereas with subversion, you cannot commit changes if you don't have You can work more easily with individual commits in git versus having a single commit ID represent the state of the repository in svn.

Access is controlled either by user/group accounts on the git server (you have to initialize the origin repository with 'git init --bare --shared' for the permissions to be set appropriately) or by using ssh keys. Very granular access control can be set up by using 'gitosis' which is a third party addon.

It takes a little while to get used to working with git when you are used to svn (we just went through this at my office), but git is way more powerful.

If you need a great walkthrough, check out http://progit.org - it's a full online copy of an open source book.

Solution 3:

In my team we are in the middle of changing our control version systems from svn to git. Git has a slightly tougher learning curve, so I started to familiarize with it and then teach the developers how to use it. They need to know all the advantages from a distributed control version systems: multiple branches, no central repository, speed, etc.

Like you, we had a system to deploy our sites so we keep something like a git central server where the changes are pulled and pushed from and to the machines of the developers. Our sites pull the changes from this "central server", and the rest of the process of deployment is similar as the one using svn.

We tried to no mix svn and git repositories, starting to migrate our minor sites and create new git repositories for main sites like they were a new version. Access is managed with ssh keys. Also we use gitweb as web interface (our svn system is http based)

It's working, it's not a change from one day to other and we are trying developers not take this change as an annoyance but a new skill to learn a tool that at the end will improve our own system.