15 September 2009

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.

3 comments:

  1. What about a free solution such as sourcefourge, google code, or codeplex?

    ReplyDelete
  2. As far as I know, these are all for open-source code. Our project may be amateur, but it's not open source... our client signed us on. The code is his.

    ReplyDelete
  3. Use a distributed version control system, Mercurial or the like, and share changes as patch files.
    You can still have a master repository if you like, and every developer (including you) can have a clone as a work-copy.
    Take a look at [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/] for a friendly introduction to DVCS.
    If you have a background in centralized VCS, you must really read this one also: [http://www.joelonsoftware.com/items/2010/03/17.html]

    ReplyDelete