>>>I am adding a VFP project to Vault from the VFP IDE and want the directory structure in the repository to automatically mirror that in the disk but don;t know how to go about it. VFP files referenced in my project live in subdirectories of 5 top level directories. The pjx/pjt files are two levels down from the disk root, and and named differently than any directory.
>>>
>>>Any suggestions?
>>
>>Don't bother. The integration of VFP IDE with any source control is buggy and the API is generally always more trouble than it's worth. I played with this several iterations few years ago, and just gave it up. Besides, if you edit something in an external editor, or in VFP without the project open, you seem to get into some kind of trouble - don't remember what exactly, because I never got that far.
>>
>>Use the Vault client on the side. Much easier. Just create a folder below $, name it whatever you want, and map it to your pjx folder, then select the files to put into vault (and files to ignore). Then have some discipline with it. After every build, label the whole project tree with the build number, so you can revert if need be. And that's about it.
>
>
>Thanks for the reply, Dragan. I am trying it now. I'd like to write a small prg to do that "discipline" stuff you talk about. Wonder if Vault can be controlled by automation?

There's an API, of sorts, consisting of a command line utility, which will blurt its output into xml files or stdout or something. You can send it commands and capture the output and thus communicate with Vault server (and I've seen code which does that, but it's 1) still buggy, 2) proprietary), but things aren't exactly clear. When you check out a table (i.e. a dbf, vcx, frx, scx, pjx or any other such file), you will want to check out any associated indexes and memo files. Then when you check them in, they may not have changed at all, and Vault will not increase the version number on them, so you may need to pull the history on all of them, to find which versions of dct and dcx correspond to 29th version of your dbc, for example, and you can't be sure that either one of them will necessarily have a smaller version number - you could have just recompiled, or packed, or changed a field of fixed length without changing the memos, or... any combination is possible.

Next source of trouble is the cache - Vault will keep loads of copies of your files locally, in places which may be configured this way or other, and under cryptic names, in a directory layout which doesn't resemble the directory layout of your projects at all. I never quite understood what does it keep and where.

OTOH, using the client is simple enough, and you learn rather quickly what to do and what not to do. One thing that has to be done early on is to split big vcxes into smaller ones - allforms.vcx is obviously a bad idea, even AllLookupForms.vcx and AllFormsWithGrids.vcx are. Regroup them by the likelihood that they will contain stuff that one person at a time may need to work on, so to minimize the wait time. Also, get everyone on the team to be disciplined and not check out stuff that is not the latest version - if they base their edits on version 17, and then when they check out they ignore the fact that the current version is already 22, they'll create version 23 based on 17, and all the changes in 18, 19, 20, 21 and 22 will be lost. Yes, Vault makes this possible - it will warn you, but you can always ignore that. Sometimes you must, because most of the forms/classes having ActiveXes in them will have some object IDs or whatnots recreated from scratch every time you build an exe, even if they didn't recompile.