On 18.05.2005, at 15:30, Mike Dewhirst wrote:
>> Actually, I think the tool he wants is 'svn update'. :-)
> OK - I'm thinking out loud here - if the website is actually a working
> copy and a cron job or human does svn update from time to time then
> any changes committed will end up in the site. Only the changes are
You can have a working copy of your site on the live server, and point
the Apache DocumentRoot at it. Then you can use "svn up" to update it
whenever you like. In this case you probably want to set up an
additional Apache rule to block access to the .svn directories. For
example, here's a solution with mod_rewrite:
RewriteRule (^|/)\.svn(/|$) - [F]
What we do is this: we have a working copy on the live server, but
Apache doesn't point at this directly. Instead, we export this working
copy to another directory, and point the DocumentRoot at that.
Actually, we made it more complicated still: Our working copy is not a
working copy of trunk, but rather of a specific released tag. And so we
don't actually "svn up", we "svn switch" to the new tag. The directory
we export to is always a new directory, with the tag name in its name.
Then a symlink points the most current export, and the DocumentRoot
points at the symlink.
Here's what our directory structure looks like:
svn/ <- working copy
release-1.0/ <- export of the working copy
release-1.0.1/ <- another export made at a later time
live <- symlink to releases/release-1.0.1
And the Apache vhost configuration for project1 has DocumentRoot
pointed at /vhosts/project1/live
We automated the update process with a short bash script. It prompt you
for the name of the tag you want to switch to, switches to it, does the
export, and outputs the command you need to execute to update the
"live" symlink -- for example "rm -f live; ln -s releases/release-1.0.2
live". So when you're ready, you run that, and the site is updated. If
for some reason you need to quickly switch back to the previous
version, it's just a simple "rm -f live; ln -s releases/release-1.0.1
On 18.05.2005, at 15:21, Duncan Murdoch wrote:
> Is there now an option not to keep the backup copies in a checkout?
> One reason not to use update on a web page is that often they have
> limited disk space, and storing two of everything is excessive.
> There are other reasons too, the most likely of which is that the user
> won't be allowed to install and/or run svn on the server, but I think
> the smiley shows you knew that.
Yes, we thankfully administer our own server with plentiful disk space
so we can do what we like with it. But you could certainly have a
working copy on your development machine, then do an export to another
directory, then rsync that directory to the live server.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed May 18 16:13:38 2005