>>I agree with your general rule on the project manager. It must be considered that the PJX is a development file too, and should be included in the checkin as every other VFP file.
>>There is the option, too, of working just with text versions and regenerating the binaries when needed, but this approeach have the inconvenience that in every checkout you must regenerate all the binaries, which can be something heavy when the project have too many files.
>>
>>About the problem of the modified VCX/SCX files because of compiling them, the apporach to solve it is really simple: you just generate the text versions, if the text files are generated then there are code changes, if the text files are not generated, then there are not code changes, so in this case in the Pending Changes View of your SCM/DVCS tool you see some binaries without their respective text files, so you need to "undo changes" on those binaries (because there are no code changes), so you keep your changed files at a minimum.
>>
>>I'm using Source Control with VFP since middle 90's, so I did have a lot of time for testing different approaches, techniques and tools. I even colaborated with some optimizations on ScctextX, which later I've used to consolidate on FoxBin2Prg, which is what our VFP teams use for diffing and merging code every day.
>>
>>Many of the problems you describe are now resolved and minimized, thankfully :)
>
>Actually the space and time are not a problem nowadays - most of the time it's not the source that's slow to bring over the wire, it's the databases. So space is not a concern, it's that switching to/from text representations has to be done from day one (or the day you pronounce so) and then every check in/out goes with text versions only, but. The trouble is that then it needs to be done in an automated fashion or it's more trouble than the current way. And that means writing my own client for whichever backend I'm using. Or, rather, writing a plugin, in VFP, which would call FoxBin2Prg this way or other whenever one of the binaries is checked in or out. I don't even know if any of the source controls allows for such a plugin - if it would, it would be worth it.

If you are developing alone or in a team of 2, then you probably can keep using SourceSafe with FoxBin2Prg, which have the automation you mention between text and binaries automatically.
Data should not be considered for checkin/checkout, because that can make explode the SCM tool. Normally data is backed up and you just checkin the text file with the structure of the data, or a few small tables full exported to text (parameter tables or some little business tables). But if you want to use the full potencial of a DVCS tool, then you don't want something like the VFP project automation when checking in/out.

One option that some SCM/DVCS tools have is "triggers" that fire before/after you checkin/checkout, which can be used to fire your own scripts to do the necessary convertions, but this have it's downsides, because when you automate too much, then you have not space left for little adjustments or use cases that sometimes are needed and that require some less automated.

Another powerful option is using external tools (sometimes they are included with the SCM/SVCS tool itself) that allow doing this stuff, (didn't totrtoise allow integrating external programs?), or scripts that can be used from the file explorer or even called from the SCM/DVCS tool, that facilitates this conversions.