Why is a merge-based SCM better than a lock-based system?
So far, our development team has used Lock based SCM (Source Control Management) control system. Recently, we have faced the need to replace the system with a new, better one.
I suggested using Git as the new system. apart from a few of us, myself included, they have never heard of Git. so I gave some explanation.
the problem is that they think that the merge system, not the locking system, is not to preserve the integrity of the source code.
although I have explained the Git system, as well as many well-known projects that have already used the Git system and an amazing reputation, they have never felt any relief in Git.
How can I make them feel relieved? and how can I explain that the merge is not a problem?
source to share
A merge-based system is no better than a lock-based system. It all depends on your project. If you have incompatible files, a locked system is probably better.
However, if I understand your question correctly, you want to know how to convince your colleagues.
It can be argued that Linux is a good example that linux development would never have been possible with a lock based system. However linux has a huge development base, maybe your team doesn't. So this is really not an argument. All the scalability and multi-user benefits don't apply unless that's a problem for you.
However, your colleagues are concerned about the integrity of the code. And therefore you must change the system. The lock-based approach is file-based. (of course there are middle solutions to this problem like svn, but let's say you are using something like cvs och vss). However, individual files are rarely distributed separately.
Thus, a change in one file will affect other files as they communicate with each other. With a blocking approach, you're never sure how your changes will affect other colleagues. If you update file A to version 2 and test it with file B rev 1, and then update file B to version 2, how do you know it will work? Why would your college even think this might be a problem? He only touched file B, why was he testing file A?
With git, you take a systematic approach to the problem. Each change is a change to the entire repository, and you can always have a version that is guaranteed to work. The point is that by looking only at the file you are screwing up the integrity of the code anyway.
source to share