Cool.

I didn't know this (or care *g*) because like I said in another post, I don't use the VFP PM direct integration with VSS and I know it doesn't try to do this unless you use that. I work with teams scattered over the US or with local teams from my home office so either way I'm remote. VSS and VFP PM over a WAN sucks! There is no kind way to put that. The VSS client over a WAN by itself could tax the most patient of people at times.

>>< snipped >
>>>Just to expand on this - it will provide a mechanism to control who can update code in separate parts of the project, and to merge changes mae by two people to the same code (I'd recommend against this, strongly - it does a poor job.)
>>< snipped >
>>Just to modify this point alittle. VSS will not allow two developers to work on the same VFP project element unless it is a PRG. Class libraries, forms, and reports are all binary files and VSS can not merge changes done to this type of file.
>
>Actually, it tries to do so, because (in theory) SCCTEXT will convert the project object to a 'non-binary' format... (eg: it converts the VCX/VCT to a VCA and stores the VCA - the VCX/VCT are rebuilt on the fly from the VCA if necessary. You can try to rework SCCTEXT.PRG - you get the source) ...but it fails miserably. I've played around informally with an XML implementation variant for the VCX with some success in VFP6. Hopefully MS will go this route in the future.
>
>It will allow two people to diverge instances of the binary, but will not re-merge them later if it decides that they are not text objects.
>
>It will allow two developers to diverge two pieces of source code from a single procedure file, but the eventual merge of the two lines of development can be at best hazardous (makes Plug'n'Pray 1.0 look very reliable.) Single checkout is the safest policy.
>
>OK?