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.

Git vs Subversion (svn): The Background

Subversion was designed to take over from CVS as the primary version control system for Open Source projects. It emerged in 2001, some years before Git, and until Git appeared, it soon became the clear choice even over very expensive commercial rivals with its simple command syntax, atomic commits and excellent tool support especially from TortoiseSVN on Windows.

Git was born in 2005 by the one and only Linus Torvalds, creator of Linux. It introduced, or at least brought to the masses some revolutionary ideas, such as its distributed nature, serverless ability and advanced automatic merging. In this video from 2007, Linus is very damning of Subversion, to the point of rudeness. He makes some valid points, especially about merging in svn, and at the time Subversion didn't have "merge tracking", so you had to keep track of what you had already merged to figure out what range of revisions to specify when performing a merge.

For a while there, it seemed that Git was going to take over. GitHub appeared as a superior alternative to SourceForge, and introduced the concept of "social coding". It introduced the idea that anyone should be able to fork any project at will, when previously this was frowned upon. Major leading projects like Ruby On Rails moved to Git and GitHub, and it looked like svn's days were numbered.

Personally I resisted Git because I was comfortable with svn and was feeling the need to minimise the time I spent on learning new technologies vs actually getting stuff done. From reading articles it seemed the Git commands were less intuitive and there were more steps involved, and the distributed nature added more complexity. However, once GitHub took off and I decided to share my core libraries as open source, I began to understand the power and importance of GitHub and decided it was the place to be. So I setup my GitHub account and learnt git enough to upload my libraries.

Several months later however, I missed the simplicity of svn and realised the GUI tools were so important for understanding and resolving a complex merge, yet the git GUI options were very patchy (SmartGit didn't exist). I also realised I could not put my 1GB repository of the past 2 years into Git and only checkout the relevent folders (what would I do with 10 years worth of projects ?) Look for a following article on this.

A new beginning

This is the first post of this blog for a new service called SVNUP.

SVNUP will enable hosted Subversion repositories with a whole bunch of important advantages over existing services. SVNUP is still in early development, but in the meantime this blog will be a place for recording discoveries and commentary related to the building of SVNUP, and Subversion in general.