>Hi Mike,
>
>I have been folowing this thread for a while now and I really could not understand why wld someone come up, or use solution that you are
>'more then proposing' here. Then in one of unrelated threads about source control you pretty much explained yourself.
>
>Keeping classes in separate classlibs DOES make sense if you were badly
>burned by downsides of using VSS or whatever else that u use. Number of VSS conflicts and related problems is realy downsized to minimum.
>But other then that, I see no other practical value to this aproach.
>
>I remember period of using VSS back in 1998 as simply - nightmare.
>Then we dropped it all together, and went back to solution where everybody had copy of full source on their local drives and master copy on (backed up) network drive.
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.
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.