Friday, September 4, 2015

Protecting critical files in SVN by means of "needs lock"

In my company we (still) make use of the SVN version control system. Yes I know this is considered obsolete, anyway I have to make use of it losing the advantages of modern VCSs, so I try to get the best from it.
We have a problem that arises for a variety of files. Sometimes someone wants to modify an important project file for experimenting or for local purposes, knowing in advance that he will not want to commit the file to the repository.
Tipical files are:
1. eclipse project files: when a developer wants to circumvent a local problem such as some automatic formatting that he temporarily does not want to take place;
2. portlet.xml file: while developing portal projects, you end up defining a lot of portlets. Deploying a lot of portlets slows down the local development a lot, so you want to have a slimmer portlet.xml file by commenting all unneeded pieces;
3. hibernate.cfg.xml: increasing verbosity and changing options in order for performance investigation and debugging purposes.

In these cases, if you want to protect the files, you could revert to using authorizations mechanisms, or using commit hooks (see here and here for example), but I suggest a quick and easy way to
obtain something that's enough in my cases. You protect the file by means of setting the "needs lock" property on the critical files plus a small "local" trick.
This way, every developer must obtain a lock in order to modify the file.
But you instruct every developer to avoid obtaining the lock. Better, they go to the local file properties and change the "read only" flag to false (valid both for windows and linux). So they can locally modify the file and every IDE will not complain.
But, should they mistakenly commit the file before deciding carefully what to do, the file won't be committed because they don't own a lock!
And the developer will understand and has the opportunity to decide what to do, in most cases, by avoiding a commit and reverting changes.
Summing up, the steps are:

  1. locate single files that developers often modify for local development purposes, plus very important file that are still meant to be public modifiable;
  2. for each one of this file, use your favorite SVN client in order to set "needs lock" to true, and commit the "needs lock" property modification as well;
  3. every time you want to modify some of the files selected at point (1), instead of taking the lock, navigate to the physical file on the filesystem and set it to "readwrite";
  4. modify the file as you want;
  5. if you do not remember to revert changes and it happens to you to commit the file anyway, the system will abort the commit operation;
  6. because of a missing lock - you still can acquire the lock if you really want to commit the file.

Although you may think this is not optimal, please remember that this procedure is quick and simple and does not involve administering SVN on the server side, so I strongly suggest it as I saw this working quite well in practice.

No comments: