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 ;-)

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 ;-)

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 ;-)

This is coming from the guy doing half of those showstopper hotfix needs deemed to hard for the real originator to handle for nearly a decade on a large app with many sub-teams ;-)

my 0.02€

thomas


>Blocking files, like normally done in last century in VFP, will work for very small teams or when you never have to make concurrent modifications on the same components (forms or libraries), but does not work for bigger teams, shared modifications and newer Source Control techniques and DVCS tools.
>
>One of the problems that was avoided with modern techniques and tools is precisely this blocking problem that my team (and others) have suffered many times: A Dev let some files unprotected (checked out) in his PC, then leaves (sick, vacation, etc) or forget about it, then nobody else can checkout those files until this Dev checkin them or undo the checkouts. This can block an entire team, and finally, at worst, you find out that many devs must work with the last copy of the SCM tool without Source Control and making copies and zips to have manual backups.... This is a recurring problem with SourceSafe and tools configured to work this way.
>
>I really don't understand why in 2017 someone want to work the old way, when we have all the options to take advantage of newer tools and techniques, like many Languages anjoy way long before Fox.
>
>Only reason that came to my mind is "because we allways done this way" or because "we think it's too difficult to change the way we work right now"
>
>Update:
>I just want to make some points on newer techniques (for VFP, not the rest of the world), because this is not just "newer for the sake of newer", because I really think that many do not know that this can be done:
>
>- You can work on the same components (forms, classlibs, etc) in different branches. Why would one do that? Well, imagine you are working on a new feature in a "FEATURE-X" branch and have done many modifications, but now you need to work solving something urgent that must be released before the new feature. How do you do that? Easy, just create a new HOTFIX branch from the last Production release, fix the code, test it and release it. Later you can merge this changes no yor "FEATURE-X" branch.
>
>- Another case: You are working on the previous FEATURE-X, but it will take longer than you expected and the client need another feature (FEATURE-Y) that is more important than feature X. What do you do? Same solution: Just create your new FEATURE-Y branch, do the modifications and release it. Then you can merge them to your FEATURE-X branch to level the code.
>
>- One more: One of your Devs had checked out some libraries and left, and you need right now some of those libraries. With old SourceControl techniques you cant (well, not if you want to work using SourceControl), but now you just make another branch from the last good one and continue working as if nothing had occured.
>
>There are many more cases I can think of, but these are the more relevant ones. I think these are strong reasons to make the change.