>>I do NOT use VFP's sourcesafe integration. That was dreadfully slow and had a habit of corrupting the sourcesafe database when multiple users were hitting it at once. For VFP I just use the SourceSafe application itself.
>>
>>For VS.NET, the SourceSafe integration works great!
>
>Thank you for the answer Bill,
>
>Can you explain a little more what you mean when you say that for VFP you just use the SourceSafe application itself as contrasted to using integration. Can you please describe the process of cheching in and out, doing builds, etc. I presume you keep your version of the project in the developer PC rather than on the network.

Integration is supposed to work with Vault as well, but... don't. Just don't.

OK, first let's #define integration. Any source control providing application publishes an API, i.e. functions callable by other software. In VFP's Tools/Options/Projects there's a place to register the source control provider - where you'll find an entry for what you have installed (so you can usually choose one or none, but it's still a combo :). Just don't do anything there, because it will then ask for every project to join its controlled counterpart out there, even for your own little projects that you will never share, and for projects where you may be using another provider. Furthermore, the high goal of integration is that source control becomes available from within VFP, i.e. from the Project Manager - every file in your project gets an additional icon representing its lock status, and new bars appear in your rightclick menu.

In theory, this should greatly ease the development. In practice, it doesn't. First, most of the source control tools can only compare text files (which makes sense, binaries are so binary), and so they need a tool (scctext.prg, or, much better, scctextX.prg in our case) to convert those binaries into texts, which complicates matters a bit. Also, it doesn't exactly keep the .pjx file in sync - you have to click somewhere to tell it to synchronize .pjm file (which is the text counterpart of .pjx, an ini-like file). Just creating a .pjm file was a major PITA last time I tried, and on second try we just went for not-integrated-ah-so-much-better. The source code repository is on another continent, so logging in there takes two clicks and four seconds. Now imagine having to go through that (or three clicks and twenty seconds if you don't want to connect) EVERY TIME you open a project, even a blank one.

If someone found where to turn these off, speak now.

As for preferred brands - tried Source Off Site, Vault and Tortoise, and liked them all. Tortoise is nagging - the so-called "integration into Windows Explorer" means it wants to be yet another app which will add a bunch of its hooks into your rightclick menu whenever you're looking at a list of files. Which may have been the cutting edge thing to do 13 years ago; nowadays it's just annoying: it means that SVNcache.exe is permanently loaded, used or not (and I use it once a month or less, for a project where I assist from time to time). The real downer is that it's so picky about filename's case - the code to go around that is in message #1251000 , but the hard part is to make sure you did run that code before quitting).

For most of the rest, Vault has practically everything running for it - a few bits may be done nicer in SoS, but nothing crucial, just a "nice to have feature". OTOH it beats SoS by using SQL Server to store stuff.