On Nov 25, 2005, at 16:56, Michel Zobel wrote:
> we have a webpage(php) stored in a subversionrepository. Now its
> comfortable to just upload the checked out directory.
>
> So my first guess would be to protect the .svn directories via apache
> htaccess and virtualhost.conf.
>
> What else could/should i do?
>
> If not i would just delete all directories named .svn. Ist there a way
> to checkout without the .svn directories? just the plain code.
>
> Anyone who already did that or has experience with that?
What's most comfortable is to have a working copy of the site on your
production server. The Apache DocumentRoot can point at that, and you
can set up Apache rules to prevent access to the .svn directories as
you suggest. When you finish development of a new version on your
development system, you can create a tag of that state, then svn
switch the working copy on the production system to the new tag. It's
quick and saves bandwidth because only the changes between the last
version and the current one are transmitted from the Subversion
server to the production web server.
Because svn switch or svn update are not atomic operations—it's
possible for these operations to experience an error which leaves
your working copy in an inconsistent state, which would leave the web
site in a possibly non-working state—we go one step further, which is
perhaps a bit more complicated but we still think it's better. We
keep a working copy on the production server and switch it to a new
tag, as I said above. But then we svn export it to another directory
whose name is the same as the tag. And we also have a symlink
pointing to the most-current exported tag. (Since the DocumentRoot is
now an export and not a working copy, we don't need to tell Apache
about the .svn directories, because there aren't any.) Once we've
finished exporting the new release, we can then simply and atomically
change the symlink to point to the new release and we're online with
the new version. And if we discover a critical error in the new
version and need to quickly switch back to the old one, that's as
easy as switching the symlink back again. We keep the last few
releases around on the server for such cases, and older versions get
removed. This is all automated by a shell script one of my coworkers
has been perfecting over the past several months, so now the process
of updating one of our sites to a new tag is as simple as calling the
script, which then connects to our Subversion server, asks you what
tag you want to get (defaulting to the most recent one), switches the
working copy, does the export, optionally runs a project-specific
setup script in the export, and prints out the shell commands to
switch the symlink, which the programmer can then perform when he's
ready.
Our site structure on our production servers looks approximately like
this:
/data/
vhosts/
project1/
data/ -- files created by the web site, e.g. uploaded photos etc.
live -- symlink to releases/1.2.11
releases/ -- exports of the 3 most recent tags
1.2.9/
1.2.10/
1.2.11/
svn/ -- working copy of the most recent tag (1.2.11 in this case)
project2/
...
The Apache DocumentRoot for project1 points at /data/vhosts/project1/
live/htdocs. (Each of our projects contains a directory htdocs which
is the Apache DocumentRoot, and then any number of other directories
for libraries and other things which don't belong in the DocumentRoot.)
If you're interested in our shell script I can ask our programmer if
he's willing to share. The script is fairly mature at this point so
I'm hoping it wouldn't be a problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 25 20:17:40 2005