>, but leaves you with another problem, namely how to be sure you've run it every time you should have

My feeling has been it may be better to use a shadow copy which contains only the text-forms of the source code (using twofox's terms for a moment, the .twofox, .scx.xml, .vcx.xml files) and write a little tool to copy changes between the two and automate all the operations like SVN STATUS, SVN UPDATE, SVN COMMIT etc (although it will still have to shell out to those commands probably)

This makes explicit that there are two completely different forms of the source code - the binary, DBF-based one that VFP.EXE edits, and the one that is stored in Subversion.

Then you'd use this tool instead of the source control features inside Foxpro, and run with a fully read-write working copy, no locks, and working practices that ensure that you don't get into a mess with two developers editing the same code. Most of the time, they'll be editing different classes in a VCX (automated merge can solve that) or one developer will be making a tiny tweak that doesn't conflict either.

Note I'm convinced of the necessity of storing a two-way text form in the Subversion repository. The binary forms are useless for anything except safekeeping, and they will blow out the repository size (svn will attempt to compute deltas but they'll be suboptimal). And the only use .SCA, .VCA, .PJM files actually are is for human-oriented diffs. They're no use for automating a merge or reversal.

The other side to avoiding binary files in Subversion is the automated locking. The BUILD PROJECT operation has some lovely hacks to recompile read-only files that don't work if your project isn't hooked up using the SCC tools. Run with a fully read-write working copy and binary files and ... well, you might start thinking a shadow copy is a good idea.

I don't want to put anyone off, I think VSS is a heap of that stinketh, and the sun shines out of Subversion's .. well, you get the idea. But it isn't EASY.