Subversion in 2010 and Beyond

http://subversion.wandisco.com/component/content/article/2-news/30-subversion-in-2010-and-beyond-see-the-presentations.html

by voxio • 17 years ago

13 30 17 years ago

subversion.wandisco.com

RiderOfGiraffes• 17 years ago

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

plinkplonk• 17 years ago

" 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.

j_baker2• 17 years ago

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.

CaptainMorgan• 17 years ago

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).

samdk• 17 years ago

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.

icefox3• 17 years ago

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.

weaksauce• 17 years ago

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.

buro9• 17 years ago

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

asnyder• 17 years ago

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.

csbrooks• 17 years ago

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

dlsspy4• 17 years ago

> 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.

stonemetal2• 17 years ago

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

angelbob2• 17 years ago

Is there a good list of these features somewhere?

icefox3• 17 years ago

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

dthakur• 17 years ago

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

angelbob2• 17 years ago

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.

dlsspy4• 17 years ago

> 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.

axod• 17 years ago

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

kogir• 17 years ago

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.

moe• 17 years ago

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.

sandGorgon• 17 years ago

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>

devdev• 17 years ago

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"

j_baker2• 17 years ago

That sourcesafe is the second most used SCM scares me.

icefox3• 17 years ago

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.

Subversion in 2010 and Beyond

Related Stories