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.


>>I'm 100% with you, I guess I did not explain well. I was hoping you could give me a process/steps or procedure so that we can do a visual compare and merge of the text file and have it properly translated back to binary.
>>
>>IOW:
>>1. I check in a binary, let's say test.vcx
>>2. I do a compare and see in the text file test.vcx the various changes. I carefully adjust the text file. This does me no good in plain VSS/SOS, as I understand it. How at this point do I make sure that my merged text file updates the binary test.vcx?
>>
>
>
>Ok, I got it now. The problem with VSS (and not sure if SOS too) is that the merge and the checkin is the same operation, I mean, you can't merge first, then process something and then checkin, you can just merge and chckin in the same step, and this is a problem, because a preprocessing is needed.
>
>I didn't merged branches with SourceSafe in the past, but used it for many many years using the simple "checkin", in which you have no problems because VSS "blocks" the file just for you, and nobody else can modify it in the meantime.
>
>What is the workflow you use with VSS or SOS? The old-style blocking method?