Our project 'source' is contained in a series of folders on our PC's D: drive and consists of the supporting web site files and the underlying application.

D:\Websites\conquestofspace.com\Live

D:\Websites\conquestofspace.com\Test

D:\Websites\conquestofspace.com\Development

As an application develops the flow should be files are copied from \Development to \Test and once testing is passed to \Live.  Files in live are then uploaded to the website, sourceforge.net and other platforms, and all files are available on your development platform.

Version control should control changes to software applications.

As an example say we have developed this first version of the website and underlying application and it all works as expected.  A month later we have decided on major changes and make amendments to the application, suddenly parts of the application stop working and we have problems finding the bugs.  Having overwritten our original code we have two choices, try and undo the changes or restore from backup.  In this case we could copy files from \Test or \Live as HTML based pages are both the source code and the final program.

The better option is to rename the initial \Development folder \Development v0.1, then when we want to make changes we copy files to a new folder called \Development v0.2 and amend only the files in folder v0.2.  In copying files to v0.2 we can either copy all the files to the folder or just pages we know we will change,  in this case any modified application in \Test would have to initially consist of all files from v0.1 with any from v0.2 copied over the top, replacing their v0.1 versions - this would an incremental change, later versions would gradually add or overwrite older files - they would be upgrades.

The problem with anything incremental (Disc backups or software amendments) you have to add up all the changes to get to the latest version - forget it!  In the days when disc space was small and costly and everything took an age to backup or copy incremental (or changes only) was the in thing, now unless you keep loads of home video on disc, space available should be far greater than you need  (I support major systems with whole databases occupying 40Gb - this would only fill half my current 80Gb PC disc which is small by current standards).

So if you are creating a new version copy all the previous version files into a new folder.

There is software available such as MS Visual Sourcesafe and Subversion on the net which can be used to control software changes (they can 'log' files in and out of a 'database' to record changes and restrict one person at a time to work on individual files, final releases of software can be built from incremental versions, but this is over the top for simple projects (and all projects should be kept simple otherwise they go wrong..) and the method above, regular backups and a little care should be sufficient. Even better document what you should do in check lists and manuals, just as the web site part of this project is attempting to do.

We may however cover use of Subversion at a later date as an exercise.

Convention used:

Documents - e.g. V1.0 where '1' is the release being worked on and .0 to nn is the amendments to the document for that release. Date last amended included in footer.

Applications - start from prototypes V0.1 to version 1.0 which is normally considered the first fully working release. Bug fixes come in .0 to nn releases for that version. Major changes increase the n.0 number. All versions 'numbers' end with a date.

Web pages - have date last amended in footer.