Any disadvantages in accessing Subversion repositories through file:// for a solo developer?

Question

If you have Subversion installed on your development machine and you don't work in a team, is there any reason why you should use the svn protocol instead of file?

Answer 1

I use svn:// for personal projects because I often work on multiple machines on the same network and I want to store everything in the repository on my desktop machine.

Answer 2

None that I know if. It should prove to a be at least a little bit faster.

Answer 3

Even if working by myself ... my protocol is to always use source control even for personal projects. It gives you a single point of backup for all of your code work, and allows you to change your mind and/or retrieve older versions.

Answer 4

If you are working by yourself on a single machine, then in my experience using the file:// protocol works fine. Even when my team was using Subversion off a remote server, I would set up a local file-based repository for my own personal projects. If you get to the point where you need to access it from a different machine, then I would go to the trouble of setting up a server-based repository. You might also look at a distributed system like Mercurial - we were evaluating it at my last company just before I left - but definitely pick one or the other, mixing svn and hg doesn't work well at all.

Answer 5

A while back on a project we were using ant to do builds. Ant would check out the latest code from the SVN repo, do the build, then create a tag in the SVN repo of the code the build was based off of. We found that the Ant automation couldn't work across any protocol except for the svn:// protocol.

So, if you want to use Ant to automate any interaction with SVN, you'll need to use the svn:// protocol.

Answer 6

You can always add a subversion server later, have it points to your file:// repository, and you'll get svn:// access immediately.

The protocol doesn't matter, it just allow transport over different kinds of medium, it's the repository content that matters.

And installing SVNSERVE later is rather easy.

However, the flavor of subversion software you use does matter though, for instance one vendor makes it so the metadata is stored in "_svn" instead of ".svn" you might want to check for compatibility first.

Answer 7

Not that I know of. It always pays to use source control, so even if file:// is in some way inferior, if it means you actually use subversion rather then get fed up with the set up and just start coding, then its OK by my book.

Answer 8

I have many different machines I work with so it's easier for me to use svn:// for the paths. In addition to that, I find that the svn path is almost always shorter than my file paths, so it's less to type.

Answer 9

I believe as long as the use of the relevant SVN tools is enabled, you should have no problem - like others said, you can always set up a server later on.

My tip then, is to make sure you can use ToroiseSVN and the Collabnet subversion client.

One major tip to ease the setup of an SVN server right now, if you choose to, is to use a Virtual Appliance. That is, a virtual machine that has subversion pre-installed and (mostly) pre-configured on it - pretty much a plug & play thing. You can try here, here and here, or just try searching Google on "subversion virtual appliance".

Answer 10

There are three reasons to choose a server-based protocol over the file protocol.

• Reduced network traffic.

When you use the file protocol on a repository that does not reside on your workstation, the entire file is written because in the absence of a daemon to process them, deltas cannot be used.

• You can expose a server-based protocol over the internet

This leaves you with the question of whether to use the svn or http protocol. Both can be used over the net. Svn has the efficiency advantage of using direct binary rather than base64 encoding. Http is easier to smuggle through corporate firewalls in the face of bureaucratic obstruction.

• Fewer hassles with permissions in cross-domain scenarios such as telecommuting.

Chances are your home workstation isn't part of the corporate domain. A Subversion server daemon functions as a proxy. It runs in an authenticated process that has the necessary permissions to perform I/O operations on your behalf.

Answer 11

There is some mention of file based and server based repositories here. Please correct me if I am wrong but my understanding of Subversion is that a repository is either a system file repository or a Berkley DB repository. The file/server distinction being made is actually just in the way that the repository is accessed. Ie the same repository may be accessed (checked out, committed to, etc) either directly on the file system with the file:/// protocol or by proxy with ssh, the svn sever and/or Apache with http.