Wiki Home

Source Code Control Standard Sample Assuming Interactive SCC

Namespace: WIN_COM_API
Some developers assume that since they are the only one working on a single project, they don't need to implement some form of source control. This is a sad assumption. A formal tool like Visual Source Safe can be used on such a project, though the practice may be rejected because it seems like overkill. However it is achieved, common sense dictates that interim versions of the development effort must remain available throughout the development cycle.

This is a place to discuss possible Source Code Control conventions or habits, assuming you are not using a formal source code control tool within VFP.
Backup: Source Code Control is just another form of backing up your work-in-progress files. The backup medium you use is immaterial, as long as you use something.

With hard disks being as inexpensive as they are, I find it most convenient to routinely backup my entire application on a second machine's hard disk, where it is readily available to test under a different operating system, to test using a different version of VFP, or simply to compare source code with what's currently on my primary machine. Various incrementally changing parts of the application environment are likewise stored on hard disk.
With hard drives being as inexpensive as they are, they're convenient for backups in general. My hard drives are removable. The cost of the drive bay and case is low.
It's a good idea to save the entire directory structure/project source code when releasing a revision of your application. This makes it very easy to do quickie bug fixes to both your working code and the released code and redistribute in an emergency. I don't know how many times I've gotten deep into development on new features that break existing code and have had to scramble for an emergency update because one of my customers found a bug in my last revision.
Library Versions: I routinely keep application class libraries in a Libs subdirectory of the project's application root directory. Since I'm likely to change a VCX substantially in the course of a work session, I start by creating a subdirectory under Libs using today's date (e.g. Myapp\libs\19990704), and copying the current state of the VCX I'm working on, or all of the application VCX files to that subdirectory.

Depending on the frequency and nature of changes, I might save daily subdirectories, or decide to eventually keep only weekly records of change. In any case, it's a good idea to have regular progresssions, going back to the beginning of the project. It's not unusual to want to know when some particular feature was introduced, or why it worked a different way at some stage of the development.
Contributors: Ceil Silver
Category Source Code Control
( Topic last updated: 2000.04.25 12:18:19 PM )