Search code examples
filesvnmergelocking

Should I lock all files to avoid merge issue when I using SVN?

I want to use SVN to control my own file(xml and binary files), should I lock all the files to avoid merge issue?

Our team want to use SVN to manage our project files, everyone in our team can edit the project files( like code files managed by svn), and our project files include xml and binary files. So Should I lock the project files while others can not commit it until I finished my edit and commit it?

Is it reasonable to lock all files to avoid all merge issues?

Solution

  • No, it's generally not reasonable to lock all files to avoid merge issues.

    The canonical resource for Subversion, the Red Bean Book, features a chapter on locking. The example there says almost everything.

    To summarize a few key points:

    • generally, there's no need to lock textual data as it can be merged
    • locking binary data can be helpful as there's usually no way to merge changes to binary data

    For textual data, locking only shifts the burden of merging from one developer to another. The essential complexity of performing a merge remains the same.

    So far, we've been talking about locking a single file. Locking everything will make sure that the right file is locked but all the others are as well. Before version control systems, some shops had all the code on a network share and only the developer in possession of a physical token was allowed to modify it. Locking everything degrades Subversion to such a system.

    In my own experience with Subversion (about 15 years in total), I have encountered few situations where whole repo locks were applied. Some of them were spring cleaning operations where structural changes were made. And sometimes the locks were motivated by high business value rather than technical reasons, e.g. when creating a release for a customer. I've encountered just as many situations where locks would have been helpful but instead somebody sent a mail to all asking them not to commit any changes.

    In closing, I've never seen something go really wrong because somebody locked or failed to lock something.