4

As lead web developer for my employer's organization, I'm responsible for configuring and maintaining an SVN repository for each of our web applications. Each has several archived versions and at least a couple of branches.

Currently, to deploy the latest version of each web site I "export" the appropriate tagged version to the directory from which Apache serves that site. For example, assuming I have a working copy checked out at /var/www/dev/app:

$ cd /var/www/dev/app/archive/1.2
$ svn export . /var/www/html/www.myapp.com

But I'd actually still like to have the live site linked to a repository version, so that I can do an "svn update" to pull over the latest updates; I just don't want any files or small modifications in the live deployment directory to be committed back to the repository.

What I'd like to do is create a read-only branch in the repository which always contains the latest production version of the application, which I can checkout to the deployment directory.

I've seen this done with a lot of open source projects, where anyone can check out a particular branch of the application but it's a read-only branch, so you can't commit back to it.

How can I accomplish this?

Brian Lacy
  • 1,113
  • 4
  • 15
  • 23

3 Answers3

4

To turn off all commits, add a pre-commit hook script that looks like:

#!/bin/sh

echo "Read-only SVN; no commits allowed!" 1>&2
exit 1

Or if you want to make just one path readonly (like one branch or something), try:

#!/bin/bash

REPOS="$1"
TXN="$2"

if svnlook changed $REPOS -t $TXN |grep -q "mybranch/" ; then
    echo "Read-only branch mybranch/; no commits allowed! " 1>&2
    exit 1
fi

exit 0

You can, of course, make whatever other checks you want in that if statement.

pjz
  • 10,595
  • 1
  • 32
  • 40
1

Add a pre-commit hook script that checks a potential commits changed paths and reject commits that commit to your specified branch unless they come from whatever user is authorized to make the branches in question.

You can also do this from the server side repo permissions, how you enact them varies depending on how you expose the repository.

mark
  • 2,365
  • 14
  • 11
1

If you are using Apache to interface your Subversion requests, you can use the Subversion Authorization file to control access to all the tag locations. From there, you can setup your web server to have its own account that is authorized as read-only to the tags folder. You can even goes as far having the web server not even having read access to anything else but the tags directory at certain paths.

If you always create a tag with same name that is used for production deployment, then an svn update will work. Otherwise, you can do an svn switch to go between tags as needed. According to the Subversion book, svn update and svn switch pretty well much do the same thing under the hood.

Now the advantage of using this, you can also provide more granular control of what your developers can and cannot do. You can also control what parts of your repositories is for public read and what parts are not.

If and when you set this up and if your web site is public, be sure to tell your web server to not serve up content in the .svn folders.

jgifford25
  • 332
  • 1
  • 5