>Years ago we also did the blocking, but that is not very practical.
>
>Let's say I have 4-5 developers in different time zones around the world. SOS/VSS is set for multi-checkout. All those developers by necessity are working on the same forms, let's say Form1 and Form2, and classlib classlib1.
>
>Programmer 1 at the end of his shift checks in any completed work. Programmer 2,3,4, and 5, will all also check in over the course of the next few hours, and their changes have to be merged together.
>
>Then on occasion a supervisor checks out the form, corrects anything he needs to, and also has to merge.
>
>There is minimal conflict between the various progranmmer's code, mostly it is a matter of adding and deleting objects or method code. Actual conflicts are maybe 10% of the time at most.
>


Ok, I see. Yours is the typical conflict resolution and merge scenario. The problem is that VSS (and may be SoS) is not the right tool for this, because it only knows about the merged file and it don't allow you to post-process something (as the text2bin conversion), which forces you to do it manually and checkin again in the next changeset. Well, anyway VSS does not use the "changeset" paradigm, because only checkin files, so this is the only way to do it in VSS, in 2 steps: 1st step with the text merge, 2nd step with the manually regenerated binary (prg2bin). And in the 3rd step you can merge again with other branch, but I've never used branches in VSS, because is too complicated.

To do all this code integration is better to use a more modern SCM or DVCS tool, in your case a DVCS may be better, because of the distributed team, and that's why I've wrote this on VFPx:

https://vfpx.codeplex.com/wikipage?title=FoxBin2Prg%20and%20use%20with%20SCM%20tools&referringTitle=FoxBin2prg


For this job, I use PlasticSCM, and I'm really impressed with it.


Regards!