[gecko]

    If any SVN dev truly believes that svn is better than Git in any technical sense then
    I wouldn't trust the engineering judgment of that developer.

Hi. Small-time Mercurial contributor and Kiln founder. I use both Git and Mercurial in my daily workflow, and only on very rare occasions touch Subversion.

Subversion is better than Git and Mercurial in at least several key areas:

  1. Access controls.  While this is not necessary for individual products, or even many
     companies, only Subversion offers the kinds of access controls that some large companies
     require.  While you can *work around* that by sharding your code into tons of repositories,
     not all companies want to do that, and I don't honestly blame them.
  2. Very large repositories.  Facebook's work on Mercurial finally allows Mercurial to
     scale to those sizes (with significant trade-offs), but Git still cannot.
  3. Very large files.  Game companies in particular need to do asset management.  Subversion
     can work with large files directly, Mercurial can kind of "fake out" working with them
     directly through largefiles, and Git forces you to use a third-party tool like Git annex
     with a custom workflow.
  4. Interop with legacy tools.  Subversion repositories can be accessed trivially with WebDAV,
     which, while I honestly think is mostly a antifeature, does allow random people in your
     office to trivially access things in Subversion directly via Finder/Gnome/Windows WebDAV
     support (and even commit, with proper settings, simply by saving).

Just because Subversion doesn't use Git's branching system and isn't distributed doesn't mean it's totally without merit, and someone so wrapped up in Git's ecosystem that they can find no merit left in Subversion is a developer who likely has an irrational approach to evaluating systems.

[einhverfr]

Agreed here. Also a point on large repositories (most of my work I prefer to do in Mercurial but there are cases where I would prefer SVN). Mercurial at least has only a minor learning curve from SVN, while Git seems to me as if leaky abstraction is the rule. Mercurial also has far better audit control features than Git (it possesses a good superset of functionality here, including two different branching systems, one of which is designed to make it easy to audit long-lived branches).

The big problem with a DVCS is that if you are doing asset control on a lot of binary files is that when someone clones the repository they need to clone all versions of all large binary files. This is a mess. Checking out a revision and working with it is far cleaner. For example, if you are doing a lot of work on, say, PSD files, you probably don't want to use a dvcs generally as it will use needless disk space and network bandwidth for marginal benefit.

As for your 4th point, there are plenty of times I refer people to use wget to get the latest version of a file on svn from a specific branch. This is actually a very nice feature. We are looking at moving LedgerSMB to github and their subversion support makes this decision easier in part for that reason.

[pswenson]

also, you can sync to a subdirectory in SVN - not git.

1) yeah, although I question the sanity of doing this. 2) is this related to #3? 3) yes, but IMO VCS should be used for source files (mostly). large assets should go in an artifact repo. But you are right - putting giant files in git is a terrible idea, especially if you change them often.

[masklinn]

> yeah, although I question the sanity of doing this.

the sanity of access control?

> is this related to #3?

Not necessarily.

> yes, but IMO VCS should be used for source files (mostly). large assets should go in an artifact repo

Great, so now the code and the assets going with the code, both being used to build the product, are completely out of sync and essentially unsyncable?

[pswenson]

>the sanity of access control? only at a directory level, git has it at a repo level.

>Great, so now the code and the assets going with the code, both being used to build the product, are completely out of sync and essentially unsyncable?

no. read up on artifact repositories. you declare the asset version that you depend on in your a build script. the assets are fetched from the artifact repo.

there pros and cons of course...

[masklinn]

> no. read up on artifact repositories. you declare the asset version that you depend on in your a build script.

Yes, that's "essentially unsyncable" when you have thousands of assets and have to keep them synchronised by hand. It has the same sanity as considering tarballs to be a good version-control scheme.

> there pros and cons of course...

I see no pros compared to a VCS which can handle code and other assets in the same repository and keep them naturally synchronised by virtue of them being naturally synchronised.

[pswenson]

you don't sync them by hand. ever heard of ruby gems, maven, gradle, npm? these assets are all versioned and available via http.

these assets can be referenced by many other systems, not just your source repo.

[masklinn]

> you don't sync them by hand.

Don't you now? How else is your tool going to know which version of an asset it's supposed to fetch from the asset store without you telling it?

> ever heard of ruby gems, maven, gradle, npm? these assets are all versioned and available via http.

> these assets can be referenced by many other systems, not just your source repo.

Wow, great, now game developers can do something they have absolutely no desire to do, at the small cost of not being able to do what they need. I'm sure they'll be thrilled.

[dasil003]

You pointed out a couple additional things I missed, but you also put words in my mouth. I did not say there is "no merit left in Subversion" and indeed explicitly stated that it does have important use cases.

However I stand by my statement on the technical underpinnings. The fact that svn does not distinguish between a repo, a directory, a branch and a tag means that it is ill-defined and is an evolutionary dead-end. Incidentally there are some benefits for things that git does poorly, but that doesn't make it a good architecture.