Individual Software Development Workflow

Infrastructure

Working on your own, you will predominantly be using Subversion as a backup and logging solution, providing you with the full history of all the files in your project. The provides you with great flexibility to rollback to previous versions as necessary and ensures that you always have at least two versions of the code at hand: the repository and your working copy.

If you work primarily on a Mac Pro or iMac then a local repository with direct file access may be best for you. However, if you split your work across two computers (for example mainly using a desktop Mac but occasionally using a laptop when on the road) then you will need to serve a repository from your desktop Mac.

The easiest way to do this is using svnserve. See the section on Setting up an SVN Server for information on how to do this.

Alternatively, if you find yourself frequently on the move then you might consider a hosted repository. Numerous providers (such as Beanstalk) provide inexpensive (or even free) hosting plans to individuals and organizations which may meet your needs.

Workflow

  1. Check out a working copy to your local Mac.
  2. Make modifications to the files in your working copy

    Undo local modifications by reverting the modified files back to the BASE revision (i.e. last update).

  3. Commit changes back to the repository

    With little (or no) potential for conflicts, you can commit changes to the repository with a granularity which best suits you. If you like to infrequently commit back to the repository then do that. This may mean going for days (or even weeks) without committing. This will work but will limit your flexibility to rollback modifications without affecting other changes that you might perhaps want to keep. However it will make your history less granular (perhaps being feature or bug-fix based) and therefore easier to follow.

    If you want to be able try out modifications and use Subversion to rollback the changes then you will need to keep your working copy relatively free of modifications. Concentrate on small units of work and commit them to the repository as often as possible. There is no disadvantage to making numerous commits per day if that suits you best.

  4. Before leaving on a trip, ensure that all code you need to take with you is committed to the repository and check out a working copy onto your laptop. If you already had a working copy on your laptop then you should update the working copy to the latest revision (HEAD).
  5. When you return from your trip, commit the changes back to the repository and then update the working copy on your desktop Mac to pull the newest changes back into your normal working environment.
  6. When you have reached a milestone, tag your project in the repository in order that you can identify that exact state again in the future. You should do this for both internal milestones and external pre-release and final versions. If you accumulate too many tags over time you can always delete them as necessary.
  7. When you release a major version of your project or product, create a branch in the repository. This will allow you to work on your next version (e.g. 1.1) while still being able to fix bugs and make maintenance releases in previous versions (e.g. 1.0.x).