Using source control with Visual FoxPro is, well, a royal pain in the ass. The project integration isn't worth the effort, and Visual SourceSafe sucks anyway. The whole idea of marking files read only to determine if you have them 'checked out' or not is just silly.

A few years ago, I started using CVS to save my VFP repositories, and instead of project integration (which completely blows, see above) I just chose to manage the source control update/commit cycle independently of VFP.

This situation was much better than SourceSafe and project integration, but I quickly noticed some problems that required me to always be manually checking to make sure everything worked correctly:

• End of Line problems between Linux and Windows
  I work on Linux as well as on Windows. I tend to work on my VFP stuff on Windows, and my Python stuff on Linux, but sometimes I work on my VFP stuff on Linux and my Python stuff on Windows. End of lines are different, and unless I'm very careful about what I'm doing, I'll screw it up. This isn't really a VFP problem. In fact, VFP allows some flexibility with the 'Save line feeds' option. It is really a multiplatform problem with CVS.
  
  
• VFP binary file format (scx, frx, vcx, mnx, pjx, etc.) results in huge repositories very quickly.
  Every time you open a classlib and then close it, whether or not you make changes, VFP saves a new version with some new timestamp information. Since CVS saves the binary file all over again with each commit, the repository gets huge quickly.
  
  
• VFP binary file format saves 2 files for each source file.
  The memo files (sct, frt, vct, mnt, pjt, etc.) need to stay in sync with the main files, but sometimes only one or the other changes. It is really tough to understand just what is getting committed.
  
  
• VFP insists on changing file extension capitalization, somewhat randomly
  Windows isn't case-sensitive, so I guess Microsoft doesn't think this is a problem. But say I have a classlib 'myclasslib.vcx' with memo file 'myclasslib.vct', and I commit that to the repository. Then later I check it out and work with it in VFP. At some point, VFP may decide to change the memo file name to 'myclasslib.VCT'. Because CVS is case-sensitive, along with the rest of the sane world, if I want to maintain continuity with my source control I need to manually change the extension back (or remember when setting up new vfp source files to manually capitalize them). A real pain in the neck.
  
  

Enter scX. I took scctext.prg, which is distributed with VFP, and extended it into a project hook that saves vfp binary files into text renditions, and loads text renditions into vfp binary files. This happens pretty much automatically as needed, and allows single text files to be saved to the repository instead of double binary files.

I've released scX to the public under an open source license, and it can be downloaded from Ed Leafe's download page at http://leafe.com/dls/vfp.

scX brings up its own set of problems, but the situation is much better for source control in my opinion. If you are struggling getting source control working correctly with VFP, perhaps you should evaluate scX.

Also note that I've switched from CVS to Subversion which is a much better product, still free. I highly recommend a scX/Subversion system.

I've also made scX available from my Subversion repository, so if you have the Subversion client you can issue the following command to get it:

	svn checkout https://svn.paulmcnett.com/Scx/trunk scX

Or, you can just browse the repository online.

scX hasn't been fully tested, and should be considered experimental. I've been using it for my daily use for well over a year now with no corruption, but consider yourself warned anyway.

©1996-2012 Paul McNett