Home | Subversion DIY write-through-proxy – Lock/Unlock

Subversion DIY write-through-proxy – Lock/Unlock

Posted on Saturday, February 23rd, 2008 | Filed under subversion

Something I didn’t cover in my original description was how to handle the distribution of pessimistic locking. This is a bit more of an edge-case than some of the others. You need to make sure you understand your options and their side effects.

There is no clean way to replicate the lock. There are two ways to work around this:

Propagating calls through the client

Setup pre-lock and pre-unlock hooks on the master repository, and have them mimic the lock/unlock operations to each mirror. Reason we’re using pre-lock and pre-unlock rather than post-lock and post-unlock is because you need to know which user is running the operation, and that information is not available in the post- hooks.

You’ll need a separate password file for http://mirror/repo-internal in which you mirror each user, and give them all the same password. That way, you can grab the username in the hook script, and simply hardcode the password. You need real authentication on the internal mirror <Location>, because locking won’t work without it.

A side-effect of this approach is that the lock tokens on master and mirror(s) will be different. The working copy will have the same token as the master repository, so the lock will appear ‘stolen’ to the client, because 'svn st -v' will query the mirror and not proxy through to the master. Other than that, this configuration essentially works.

Replicate the relevant parts of the repository database

Setup post-lock and post-unlock hooks on the master repository, and have them rsync the contents of the <repository root>/db/locks directory from master to mirror(s). This ensures the lock token is the same between client, mirror and master. Of course, any untimely breakdown in connectivity between master and mirror(s) in this scenario could lead to unpredictable results and repository corruption. None of this should endanger the integrity of the master repository however, and recovery should be fairly straight-forward.

Comments

Leave a Reply