git vs Subversion - pros and cons

Question

I have been a user of SVN for many years now and I can't say I am totally happy about it. Few days ago my partner asked me to take a look at git saying that "it has better performance, easier merging and branching."

I've been reading some git vs. SVN comparison articles and I'd be happy if people could sum up the pros and cons using both version control system.

Now I am looking into people who've switched from one system to another and hear subjective opinions.

I know for myself that I really like the way SVN works, having one central repository where people can checkout from, knowing I can deploy from it a live developement copy and a live production copy, but sometimes we have headaches sorting conflicts or other errors and each time we need to diff or look into the history of a file, we have the network latency to deal with.

On another hand, having a distributed platform sounds like a headache aswell, how can you control accesses? do you have one central repository where you push and update from?

Thanks for shedding some more light on the issue.

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.

Comments

[Joshua]

svn can handle larger files than git

[Aaron Brown]

I was unaware that git had a maximum file size - what is the limit?

[uno]

It's mostly that since Git carries the history around with every working copy, a large, heavily edited file will take up a lot of space. If the large file is essentially unchanging, it's fine

[Walter]

I would say that Joshua comment is misleading. The files that a checked out are the same size for both SVN and git. What will happen is that because git keeps a copy of the repo information locally, the total disk space required for all the files plus the repo history will grow as you edit the files, but for SVN this space is fixed (as repo history is not stored locally).