SOLUTION: "svn: No repository found" error with svn+ssh on the same host

I had a strange problem where a SVN working copy was working fine on one machine, but after file copying it to the same machine that the svn server lives on, any server accesses would fail with "no repository found". The breakthrough came when I tried to ssh in as the svn user, which should connect directly to svnserve and give some gibberish back, but instead was logging in with a waiting shell prompt. 

Why was this happening from the same machine and not another machine ?

The problem turned out to be how sshd authenticates. Somehow it wasn't trying the correct key in the .ssh directory, and defaulting to a password login.

The solution was to specify which key to use on the client side when connecting as the svn user for the svn server.

eg. in ~/.ssh/config :

Host your-svn-server.com
    IdentityFile ~/.ssh/your-svn-key.ppk
    User svn

SOLUTION: svn: Can't open file '.svn/text-base/somefile.ext.svn-base': No such file or directory

I was getting this error and it seemed my working copy was corrupt. A sure fire way to fix this, if you can afford to, is to remove or move the folder with the error and update to get a clean copy. But just now I had this with a folder of 300MB of images.

The following quick hack worked though :

1. copy some other file like .svn/text-base/somefile.ext.svn-base in the same folder to .svn/text-base/somefile.ext.svn-base
2. update to a version of the repo before somefile.ext existed (or maybe changed - not sure) like this "svn update -r XXX"
3. update to the current version "svn update"

The above should get past the error by having a correct-looking file in the expected place. We then cause that file to be replaced with its correct content by causing svn to overwrite it

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.