>Fernando,
>
>technically you are spot on with the things *possible* if branching/merging is used to the utmost.
>Still, I'd hesitate to train a dev team to do the best on that frontier ;-)
>
>Developing x+n different branches will slow the devs down just from own mental parallell processing. Teaching those responsible for spec sheets that retracing/jumping needs/not thinking things through to the end WILL ALWAYS balloon development cost is better than streamlining the dev process to allow them even more muddy thinking ;-)

Ditto. Just having one branch and having to merge some changes after a while was very difficult the first few years, and caused a lot of headaches, time lost and bugs in obscure places where one last detail of the merge process was forgotten. BUT: this has taught us of the pitfalls and we learned how to better organize the code, to encapsulate better (bizobjects are our best friend!) and also of tagging all the places where the original code in a vcx was changed. I actually have an intellisense macro which--- well here it is:

lparam oFoxCode
oFoxCode.ValueType="V"
lnHours=SET("Hours")
set hours to 24
lcSetDate=set("date")
set century on
set date ymd
lcReturn= "*["+ttoc(datetime())+"] " +getwordnum(sys(0),2, " #")+ " -"
set hours to lnHours
set date to (lcSetDate)
return lcReturn

so this inserts a comment with a timestamp and username plus whatever I write after it. When merging, just searching for the dates when the code changed helps to find all the places.

>Yes such cases do happen, but it should be the exception. And at "exception rate" you can handle it with traditional locking strategies, giving devs a saner mental frame to concentrate working in ;-)

Yup, the last time I had to merge something I did it about six times faster than when we started.

>The problem areas you cite clearly exist, but are not show-stoppers as they can be brought under control just using sane guidelines:
>Every dev is responsible to either check in each day or be prepared to merge his changes after forced undo checkout in case of illness.
>While Mikes 1 prg per func / 1 ?cx per class/form is too strict IMO, striving for sane, small file sizes helps a lot ;-)

And it's not the size per se, it's chopping the classlibs into functional units - a form which is just a dialog to aid getting exact tire sizes shouldn't go into forms.vcx but into tires.vcx, along with the form where the rest of tire stuff happens. Also, framework stuff shouldn't be in these job related vcxes - generally, keep things which are used together in one place, things which are used everywhere in framework classlibs, and don't put unrelated things together. This way, the case when I want to edit a class which is in a classlib locked out by someone else happens perhaps once a month, and is resolved within a few minutes. Sometimes it's resolved by shuffling the to-do list, i.e. I leave my thing for the next day and do something else, but the decision on whether the guy keeps it or hands it over takes five minutes.