>I worked on two projects where programmers were spread across the continent. We used VSS in both cases, with SourceOnSite for communications. In both cases we used SoS to synchronize with the VSS database and the master copy - and stayed away from integrating the VSS with VFP. The interaction between VSS and VFP's Project Manager was proven to be a nightmare, unless everybody knew the tricks, which neither project could afford.

Well I don't know about this scenario with telecommuting, perhaps in this case apropriate tool is necessary. Bigger dev. shops most probably
also need versatile source control tool, but up to 5 VFP developers
scenario I described work just fine.

BTW is there any stats how meny shops are having MORE then 5 VFP developers? Or this is history now with NET tidal wawe ...

>
>As to grouping multiple classes into one vcx - I'm with Mike here. The only reason I'd have two of them together would be that I know for sure that one would be used nowhere else but in the other one. The only exception is the framework itself, which sits in one large vcx, all 30 or so classes. Everything else is in a separate vcx or prg. Careful naming is needed, though, because there's no other way to keep things grouped in ProjectManager.

Are we are talking about regular GUI building classes
of business objects ?
I just cannot imagine (aldough I will try to see :)) having
to switch library everytime I want to add something to my form...
Or having to issue arrays of 'set classlib to ... additive' statements
when you are adding objects on the fly.

If I remeber correctly, at the VFP beginnings, everybody was advicing (I and perhaps many other people folowed it) , having all VFP baseclasses subclassed in one library and then subclassing it from there, for further addition of functionality.
Over period of years everybody perhaps built their controls and other common libraries according to their standards, needs, frameworks etc.

To sameone who did this, concept discussed in this thread really does not sound apealing ...

For bussiness objects especially if they are huge, maybe it could be usefull. But I wld not know as I am building those (my version of it) in PRGs usualy. And even there they are bunched up together in one prg per database / project.
This is from one side my personal preference (code window), but also
choice of 'session' class as main 'driving force' behind almost everything
I do with VFP.

So to square this, I see concept proposed in this thread rather as PERSONAL
file/class organization preference - then sound guidline to follow.

Just my 2c
(Ili ti dve banke :)

Rgds+++
Srdjan