You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Michel Zobel <zo...@hnw-online.de> on 2005/11/25 15:56:37 UTC
SVN Files in Productionenvironments
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
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?
Thanks in advance
- --
Michel Zobel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
iD8DBQFDhzQ1z7Hv5q8V14URAhwJAJ9y7FOgNESu6z50i8kiqFqqBfqiqQCfaoG/
tOybb6J0x695408Vl1AlRzs=
=oS4h
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN Files in Productionenvironments
Posted by Dan Falconer <li...@avsupport.com>.
On Friday 25 November 2005 10:05 am, Greg Thomas wrote:
> On Fri, 25 Nov 2005 16:56:37 +0100, Michel Zobel <zo...@hnw-online.de>
>
> wrote:
> >So my first guess would be to protect the .svn directories via apache
> >htaccess and virtualhost.conf.
> >
> >What else could/should i do?
>
> Checkout http://subversion.tigris.org/faq.html#website-auto-update
> which covers it.
>
> >If not i would just delete all directories named .svn. Ist there a way
> >to checkout without the .svn directories? just the plain code.
>
> Sure - just use "svn export". Though this loses you the ability to do
> a "svn update" to get the latest version.
>
> HTH,
>
> Greg
We also have a website that uses SVN for version control. We have the live
server running from the "trunk", instead of a tag, due to the frequency of
updates. Keeping that in mind, I'd like to point out that the
afore-mentioned FAQ
(http://subversion.tigris.org/faq.html#website-auto-update) makes the
assumption that the repository and the referenced website exist on the same
machine: in our case, the repository exists in an internal network, whilst
the live server exists in the public network. Thought it might be pertinent.
--
Best Regards,
Dan Falconer
"Head Geek",
AvSupport, Inc. (http://www.partslogistics.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN Files in Productionenvironments
Posted by Greg Thomas <th...@omc.bt.co.uk>.
On Fri, 25 Nov 2005 16:56:37 +0100, Michel Zobel <zo...@hnw-online.de>
wrote:
>So my first guess would be to protect the .svn directories via apache
>htaccess and virtualhost.conf.
>
>What else could/should i do?
Checkout http://subversion.tigris.org/faq.html#website-auto-update
which covers it.
>If not i would just delete all directories named .svn. Ist there a way
>to checkout without the .svn directories? just the plain code.
Sure - just use "svn export". Though this loses you the ability to do
a "svn update" to get the latest version.
HTH,
Greg
--
This post represents the views of the author and does
not necessarily accurately represent the views of BT.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN Files in Productionenvironments
Posted by Ryan Schmidt <su...@ryandesign.com>.
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