Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Subversion in 2010 and Beyond

subversion.wandisco.com

Post reply on HN
Print view View original

21–30 of 32 posts

Re: Subversion in 2010 and Beyond

#21

Post by kogir »

RiderOfGiraffes wrote: post #2

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

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.

Re: Subversion in 2010 and Beyond

#22

Post by weaksauce »

icefox wrote: post #10
RiderOfGiraffes wrote: post #2

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

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.

Re: Subversion in 2010 and Beyond

#23

Post by kree10 »

j_baker wrote: post #7
plinkplonk wrote: post #3

Earlier quoted context omitted.

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

Re: Subversion in 2010 and Beyond

#24

Post by sandGorgon »

RiderOfGiraffes wrote: post #2

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

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)

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.

Re: Subversion in 2010 and Beyond

#25

Post by moe »

kogir wrote: post #21
RiderOfGiraffes wrote: post #2

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

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 smal…

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.

Re: Subversion in 2010 and Beyond

#26

Post by sorbits »

angelbob wrote: post #16
stonemetal wrote: post #12

Earlier quoted context omitted.

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.

Re: Subversion in 2010 and Beyond

#27

Post by stonemetal »

sorbits wrote: post #26
angelbob wrote: post #16

Earlier quoted context omitted.

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 anot…

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

Re: Subversion in 2010 and Beyond

#28

Post by dlsspy »

angelbob wrote: post #17
RiderOfGiraffes wrote: post #2

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

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 inconven…

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

Re: Subversion in 2010 and Beyond

#29

Post by dlsspy »

buro9 wrote: post #11
RiderOfGiraffes wrote: post #2

I'd be interested to hear the opinions of HN'ers. Is there any reason these days to choose SubVersion over 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

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

Re: Subversion in 2010 and Beyond

#30

Post by dlsspy »

sorbits wrote: post #26
angelbob wrote: post #16

Earlier quoted context omitted.

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 anot…

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

Post reply on HN