>>I have used TFS for many years, and just recently I implemented source control using TortoiseSVN. I also tried out Bitbucket which is great especially for very small teams because you just create an account and save the work in the cloud, so you can implement it very quickly without any hassle, all you need is an email account.
>>
>>My personal preference when using Source Control with VFP is to avoid conflicts and don't attempt to merge changes. That means you need to lock the files, so only one developer can edit a file at the same time and needs to check in the changes before another developer checks it out. In TFS it is the action Checkout > "Prevent other users from checking this file out". In Tortoise I added the property svn:needs-lock and the locking can be done in Tortoise right click menu or also with command line tools that you can implement in VFP. That may not work well with older projects when you have large procedure files with hundreds of procedures in one prg, or class libraries with hundreds of classes, but for quite some time now I break down the code into smaller pieces that work more independently from another and then the system is working really great. A nice benefit from locking is also that I can see who is currently (or supposedly) working on which files or parts in the program, and I can also see how long they have it locked already.
>>
>>That means in VFP the source code is readyonly and in order to make changes you have to checkout and lock the file.
>>
>>When using TFS it is important to set the option "Get latest version of item upon checkout." Strangely enough this option is unchecked by default, and that would mean you could accidentally checkout and lock an old version of a file when another developer has done changes and you did not get latest. Then you get the surprise when checking the work back in that there is a conflict.
>>
>> SPX, FXP, and MNX need to be excluded and put on the ignore list.
>
>Hi Christian:
>
>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.

You are certainly correct that it is possible to do merging and solving of conflicts also with VFP. The reason why I did not go that route was just personal preference, also taking into account the specific project and size of the code and size of developers. So it is certainly not the only way to work but it is one way that has proven very stable and easy to use in my experience.

For instance now I introduced source control for an old VFP Project that has several hundreds of public variables, and the entire project was converted from a fpw26 application. Again I made the choice to work with locking because that seems to be the safest way to avoid any errors in the code.

Regarding locked files, I never had a problem with that issue before. TFS has administrator tools that allow unlocking files that accidentally were locked, TortoiseSVN can easily steal a lock from someone else without special admin rights. Besides, I encourage developers to work on small bite pieces of code and regularly check in their work. For me source control is not only for coding but also a means of keeping backups of work, because the worst case scenario is that a developer has hundreds of hours of work on his laptop and then drops the thing on the floor.

I also looked at vcx2prg to do merging and comparing of vcx libraries, but my previous project had close to 2000 class libraries and it would have just been too time consuming. Maybe there are other ways to do that?