BTW! David, I recently had an epiphany! Some people think I mean ONE ROW in a VCX! That's not what I mean at all. I mean use the VCX exactly like the SCX. You'll notice you cannot put multiple screens in one SCX.

In the SCX is the screen and all of it's components - components which SHOULD be subclasses. Likewise, IMO a VCX should contain a single class and its subclassed components.

>Mike,
>
>As a followup to this - we've been following your suggestions, and they have been working exceptionally well. The first thing anyone does now if they need to work on a class is to break it out into it's own vcx if it is not already. We are still getting the occassional collision which I don't see as avoidable (i.e. one person is working on a release branch bug fix while another is working on an enhancement branch).
>
>But by adhering to a strict commenting convention, we have been successful at merging in those few instances (we just do it manually).
>
>So thanks again for the suggestion! It has saved our hide!
>
>David
>
>
>>Hi David
>>
>>I've been struggling with exactly the issues you're looking at now. My solution is to significantly reduce the number of classes per vcx and the number of functions/procedures per PRG to near one-to-one.
>>
>>No two developers then ever work on the same atomic piece. There are also no contention issues and no extra steps to take.
>>
>>I still use source control, but only as a backup, not as a way to attempt to resolve conflicts or merge code.
>>