Git vs Subversion (svn) : The major downfall of Git - no partial working copies

The major downfall of git is that when downloading a working copy of a remote repository, you cannot checkout (clone) anything less than the entire remote repository. Conversely, with Subversion you have a URL for each file and folder on every branch of the repository, and you can checkout individual files or folders if you wish. Any checked-out folder ("working copy") is fully functional, and can be committed back to the remote server. With svn you can have multiple partial working copies of a single repository.

This means that Git forces you to use multiple repositories, while svn will happily support single or multiple repository scenarios.

If you have a single project, or your projects are all independent, Git my serve you well.

A) Reasons for multiple projects in a single repository

1. You can branch, merge and tag related projects together
2. Avoids reconfiguring users, permissions, and possibly IT staff intervention required for a new repository
3. To keep the company's prime assets in a single, controlled, easily backed up location

B) Reasons for seperate repositories

1. Security - but svn allows permissions to be specified per folder
2. For temporary experimentation
3. When projects and teams are truly unrelated, or you have other ways of managing versions and interdependency

The weight of reasons under A are much greater than under B. In fact the reasons under A support choosing svn, while the reasons under B do not support rejecting svn.