Version Control for the Server-Challenged

Some background: there are three of us working on a large project. We are not located in the same city; two of us are about an hour's drive away, given traffic, and the third is in a totally different region of the country. Each of us is developing web pages on her own machine at home, sometimes coming in to school and developing on her own (desktop) machine there. That means that at least six versions of the code exist (one for each location). Usually, we work on discrete sets of pages... but not always. For example, if I am working on localization and Liora is working on authentication, we each need to make small changes to ALL of the pages in the set.

The solution to our problem should be a version control server, like Subversion. If we were all using Visual Studio proper, we could even use an add-on called Ankh to integrate Subversion with the IDE. (I personally am using Visual Studio Express at home, so that won't work, anyway.)

The issue with this solution lies in where to store the repository - the central "original" from which all copies are checked out and to which all updates are committed. Subversion (and its client applications like TortoiseSVN and AnkhSVN) offers five options:

1. local file
2. http (on an Apache server)
3. https (same as above, but secure)
   
4. svn (on an SVN-enabled Linux server)
5. ssh+svn (same as above, but secure)

Students are notoriously short on cash. The obvious result? We can't afford our own web server for this project. While we each have space on our school's web server (some of us even know how to access that space), we don't make the decisions of what software that server will run. I tested to see if our server is already running Subversion or CVS, its predecessor. It is running neither.

This being the case, how will we manage version control?

The only option left open to us is 1, the local file. Local where? Well, since this is my idea and I'm working on my home machine, local here. And then everyone else will need to send me their versions for periodic commits and updates. This is not optimal, because it turns the engineering problem (where the tools would force the appropriate action to ensure correct results) to a personnel problem (where with every additional worker, the chances of something grow wrong increase). Whip cracking might be in it.

Life's not fair. But we can get by.