Is there a way to force an SVN file update before locking that file?

user_17091066 0
Viewed 63

Question: Is there a way in SVN to force a file update when a binary file is locked? This would appear to solve the issue we are having below, by forcing the locking action to update the file to the latest revision before editing.

Background: I am using SVN (TortoiseSVN) at work for revision control as an electrical engineer. Many of the files we have in SVN are binary design files which cannot be merged if there is a conflict. On these binary design files, we have the "svn:needs-lock" property set.

Issue: We have had a few cases where two engineers (Eng A and Eng B) have a binary file (File 1) checked out at the same revision (Revision 1000). Eng A locks File 1, makes edits, and then commits File 1, which means Eng A now has File 1 at Revision 1001.

Now Eng B wants to make an edit to File 1. However, he is still on Revision 1000 even though the latest changes in SVN repository are Revision 1001. Eng B locks File 1, makes his edit, and then commits his change and is now at Revision 1002.

The issue here is that when Eng B made his commit, his edit was not based on the changes of Eng A at Revision 1001, but instead his "outdated" Revision 1000. This results in Eng A's changes at Revision 1001 getting erased.

tortoisesvn version-control svn
1 Answers

Unfortunately just using the svn:needs-lock property is not going to work in most use cases. This is because the svn will try to use the filesystem-level permissions to make the file read-only. Then it is upto the application of the binary file to inform the user if file is in read only state. But most modern application just simply removes the read only tag and starts to overwrite. You can read more about why it is not implemented in hard way here. The information here shows the "softer" approach of subversion for locking policy.

I had tried to implemented a stricter lock policy using the pre-lock and post-lock hook scripts. But was becoming way too time consuming to maintain from the administrative perspective.

What has worked wonders with no admin headaches, for atleast smaller teams(10-15) is the pre-lock and post-lock notification. Whenever some one locks a path a notification is send to people in the group that the file is locked with the name of the user that has locked the path,alerting the users not to lock them or updating them. When the lock is released another notification is send to the group informing the lock is available to take.

This very simple lock and unlock communication reduced the rate of overwriting the work to almost 0. There were still some new comers that just started working without checking whether the file was locked or not.

user_81235070
Related