I had a quick discussion on the IRC channel today about locking entire directories in my repository. [1]
My company recently submitted version 4.0 of our application to Apple's App Store. That submission was created from a tag which was itself created from the 4.0 branch. While we're waiting for that to be approved, we are merging fixes from the trunk down to a newly-created 4.0.x branch, keeping the 4.0 branch around to accept any hotfixes Apple's review process demands. This two-branch setup lets us get a point release up and running as soon as possible after release without jeopardizing the review process of our 4.0 by unknowingly adding in more changes than Apple requests. This morning, one of our employees accidentally merged work to the 4.0 branch that should have been merged to the 4.0.x branch. Thankfully, the product manager caught it a few hours later. But to prevent this from happening again, I want to put an advisory lock on the 4.0 branch. Unfortunately, a failed `svn lock` and a little Googling revealed that Subversion does not natively support directory-based locks. The general recommendation is to configure path-based authorization, but that won't work for us for two reasons: - We use svn+ssh:// to connect to our server. - The lock needs to be breakable so that engineers can confirm they really do want to merge a hotfix down to the 4.0 branch. The only remaining alternative seems to be a repository hook that rejects checkins which touch descendants of the 4.0 branch. I can whip one of those together, but it's really unfortunate that such logic isn't built into Subversion in the first place. Being able to lock an entire directory also has a major benefit to OS X users by making it possible to treat document bundles as atomic units. For the unfamiliar, OS X treats certain types of directories as atomic documents. This lets application authors mmap the constituent files for increased performance. But since `svn lock` can't be applied to directories, such a compound document can be corrupted by adding unexpected files. I understand that implementing this would require all commits to search for lock properties on every ancestor of every changed file or directory. It essentially amounts to an extension of inheritable properties to the RA layer. Which would be pretty neat, IMO. :) Shall I file a feature request? --Kyle Sluder [1] http://colabti.org/irclogger/irclogger_log/svn?date=2014-01-13#l189