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
Received on 2014-01-14 04:15:06 CET