Subversion in 2010 and Beyond | Hacker News Reader

Subversion in 2010 and Beyond

subversion.wandisco.com

13 pointsvoxio30 comments

Some interesting data from a survey: http://www.ddj.com/architect/222301141

Quote: "More than one-third of developers use Subversion for source code management; that's almost triple the share of the next most used SCM tool, Microsoft SourceSafe"

That sourcesafe is the second most used SCM scares me.

It is always fun seeing stats like this. Almost all of my friends have moved over to Git (one is on hg) so it is a fun reality check that Git is still small and has a long way to grow.

I'd be interested to hear the opinions of HN'ers. Is there any reason these days to choose SubVersion over git?

" Is there any reason these days to choose SubVersion over git?"

Well sometimes your co workers are too .... old fashioned... to grok git. Work in a large enterprise sw company to see this at full effect.

This. I think that the question that most large software companies are asking is "Is there any reason to move to git over subversion?" And in a large software company, that's a pretty big question. In fact, discussing it would likely take more time than actually moving to git.

This is where git can be more subversive than svn ever was. You need one (influential) developer to start using git-svn, and wait for it to spread.

To the best of my knowledge, git is for smaller teams that need more of an ability to be dynamic (maybe web apps dev) whereas subversion is for larger teams that need centralization (network/server; maybe large systems - however Torvalds would disagree here since git was initially for kernel dev).

Having Git be a distributed VCS doesn't mean it can't have a centralized server though. If you want you can use Git as something very similar to Subversion--you just lose out on a lot of the nicest parts of Git.

I think the biggest challenge with using Git in a large organization is training a large number of people to use it. You can do a fair amount of development on a Subversion project knowing just how to update and commit. The same does not hold true of Git.

> I think the biggest challenge with using Git in a large organization is training a large number of people to use it. You can do a fair amount of development on a Subversion project knowing just how to update and commit. The same does not hold true of Git.

Is that because you also have to know how to push?

You can push git down to the LCD and have the same dumb VCS workflows. I think some people get hung up on thinking that new features being available must mean that you need to incorporate those new features into your workflows.

1) You don't know Git, but everyone in your group knows subversion. 2) The existing projects are already in subversion 3) The Subversion GUI tool which from the presentation it looks like a good portion use.

That is still not a reason not to use git on your personal machine. These use cases are exactly what git-svn was made for.

If you are comfortable with SVN then by all means use it but if you haven't at least tried Git you are missing out on some really powerful tools and workflow possibilities.

If you have a lot of binary files then maybe subversion might be a better fit for you. But even then the local directory size can be smaller with Git.

We've had this debate before, but something along the lines of:

* No GUI for Git on Windows

* Everything knows how to work with Subversion already (tools, testing, continuous integration, idiots)

* Companies like centrally controlled and backed up solutions

* Why change when what you have works for you

What do you mean no GUI for Git on Windows? There's the excellent TortoiseGit http://code.google.com/p/tortoisegit/, along with numerous other tools that you can find on the Git wiki.

The same guys who make SmartSVN, have SmartGit now...

> Companies like centrally controlled and backed up solutions

git wins fast over svn for backups.

git backups are redundant, always up-to-date, easily verifiable, and easy to turn into proper master repositories.

The more people you have working on a project, the harder it gets for anything to get lost.

To be fair to the subversion guys, its pretty darn easy to setup real-time backups. Use svnsync and hook it up in some post-commit hook.

Having said that, to have git completely backed up, it's not as simple as a clone. You will need to mirror another repository so that you can get all of the branches, tags, etc. Additionally you will need some sort of post-receive hook so that your mirror is kept up-to-date.

Now, my conclusion with backups for svn and git - both need some intervention. Its not as simple as "press this button and it just works".

Subversion has features Git doesn't and can't support.

Is there a good list of these features somewhere?

I am not sure what exactly the original poster is referring to but the main feature of svn that git can’t do is treat each directory as its own repository.

So if you make a repository like:

  src/
  libs/
    my_debug_lib/
    my_core_lib/
  etc/

In svn someone can checkout libs/my_debug_lib and treat that as its own repository (ignoring the directories above that level).

A secondary thing is “externals”. With svn you can add another repository as a directory. Git has submodules, but it is not the same and more cumbersome (for example each time the remote repository is updated, you need to perform a local commit to bring your reference up to date with the remote).

I guess a third svn feature is file properties.

The can't support was directed at file locking, which is mainly useful for binary files that can't be merged.

> Git has submodules, but it is not the same and more cumbersome (for example each time the remote repository is updated, you need to perform a local commit to bring your reference up to date with the remote).

It's simply not revision controlled if two different checkouts of the same version produce different source trees.

externals might be convenient for moving targets, but that's entirely wrong behavior for a revision control system.

Do you mean "Git has features Subversion doesn't and can't support"? :)

Ain't broke, don't fix it..etc

Git is significantly more complicated to learn, basically because having an additional level of repository and no default upstream repository makes for more moving parts. Git also has more flavors of branch (tracking or non) and repository (bare or not), and more ways to edit changes (cherrypicking, rebasing).

So basically, more moving parts means it takes more time to figure it out. For you or me, that's an inconvenience and then happiness about all the cool features and capabilities. For a corporation trying to keep their training budget low, that's a non-starter.

> Git also has more flavors of branch (tracking or non)

Use the default.

> and repository (bare or not)

Use the default.

> more ways to edit changes (cherrypicking, rebasing)

Use the same ones you use in svn.

> more moving parts

git has four object types that are put together very naturally (tags contain commits which each contain a reference to a parent commit and a tree which contains a collection of other trees and blobs).

This means that when something goes wrong, I can fix it.

svn has at least two server-side object formats, and various version changes that make some features available or not based on client and server capabilities.

Backups are harder, repair is harder, history traversal is harder, sending changes around is at the very least slower.

In my experience, interacting with git is no harder. I've taught many people how to use it and the only people who were remotely confused were those with a svn background, as the svn unlearning process generally takes more time than the git learning process.

It's like debating which is better reiserfs or ext2. for 99% of people, they don't care. Both work.

We tested git and hg at Loopt:

While both were faster than SVN (often much faster), they have huge disk footprints compared to an SVN working copy. In our case, the SVN working copy was ~1GB, and both the git and hg repositories were over 20GB. That matters when you have an 80GB SSD.

Also, since neither git nor hg let you check out a subset of the repository, we'd have been forced to break things up into lots of smaller, separate repositories, a prospect we dread.

Admittedly, we do some stuff that is questionable, like storing images and libraries, but we like keeping all the content the code uses and the code itself together.

For some newer, more isolated projects, like our mobile code bases (iPhone, Android, etc), we use git and love it. But for our 4 year old server with over 100 projects, we couldn't realistically make the switch.

Admittedly, we do some stuff that is questionable, like storing images and libraries

Not questionable at all. We do the same thing, all the way down to storing tarballs of software-packages a project depends on - it is the right way. The blame is on git here for not supporting it better. I.e. it should be much easier to selectively truncate history or even define an object-level attribute like "Only keep the last 3 versions of this".

Regardless we're getting along with git quite well, despite .git sizes in the gigabytes for some projects.

Our main complaints about git are access control and sub-projects at this point.

Subprojects ("submodules") in git are a royal pain in the ass. I consider them broken-by-design. A simple equivalent to svn-externals would work so much better...

This, combined with the complete lack of directory based access control, makes it rather cumbersome to work with "partially trusted" third parties in a commercial setting. We don't want to open our entire repository to some temporary contractor. Neither have we found the hassle of git submodules worthwhile for this purpose.

That's why we're still using SVN in this area, although I'd much prefer if we didn't have to.

Partial checkouts. I used to work in the semiconductor industry, where HDL Netlists can go upto several GB. If you are in the EDA industry and you need to test your tool on a Netlist or two, you dont want to be checking out the entire test-tree.

I suppose partial checkouts are critical for several other fields - for e.g. take a look at a similar request for Mercurial (http://mercurial.selenic.com/bts/issue105) Message 8102:

Two of the features that made it difficult to 'sell' Hg for the main SCM of FreeBSD were the lack of partial checkouts and partial history

And because of the way legacy code is structured, this gives rise to issues like this one - http://jira.codehaus.org/browse/MRELEASE-457

For several use cases, this is a highly critical feature and the reason that SVN may win over finally - perhaps as SVK (svn's distributed revision control fork)

<empirical-observation> The transition from cvs to svn happened very quickly, to the extent that it is now the predominant SCM. The migration tools are robust today, but they were not so a couple of years back - which is why it is even more suprising that people were willing to undergo the cvs2svn pain but are not willing to do the relatively painless 'git svn clone'. Maybe git truly doesnt suffice in a LOT of situations. </empirical-observation>

Reply on news.ycombinator.com