On 25.06.2005, at 20:25, Jan Eri wrote:
> I thought I had this under control with Bens pointer to <http://
> subversion.tigris.org/faq.html#website-auto-update>
>
> But I have discovered a problem when I perform a copy from my trunk
> to the tags-directory that my live-site is a working copy of, tags/
> site1:
>
> The first time works fine:
>
>> svn copy trunk tags/site1
>> A tags/site1
>
> But the second time, when 'site1' already exists:
>
>> svn copy trunk tags/site1
>> A tags/site1/trunk
>
> in other words copy assumes that I do not want to overwrite, and
> instead adds directory trunk to site1 - which is not what I want.
> How should I handle this better?
>
> It seems a bit strange that the same command gives different
> results like this.
Subversion's copy command works the same way as the Unix copy
command, this is therefore expected and desired behavior.
The web site auto-update pointer above is, I feel, primarily geared
towards people wanting to auto-update a development copy of the web
site, which would always follow trunk or a particular release branch.
We do this on our development server, which simultaneously serves as
web server and Subversion repository. Once someone checks in
something under project1/trunk, a post-commit hook updates a working
copy of project1/trunk on the server. A particular URL on the web
server points to this working copy, so management and other users who
don't have a working copy of the project can see its current version.
When someone checks in to project1/branches/1.0, a separate working
copy of branch 1.0 is updated, and a different URL on the web server
points to this working copy. Similarly for any other release branches
we're still maintaining, and similarly for all our other projects.
But for deployment to a live system, you're should probably make a
tag. Of course you're free to do it any way you please, but the
conceptual definition that Subversion proposes is that a tag, once
created, does not change. It indicates a snapshot at a point in time,
so that you can later answer the question "What was version 1.0.5
like?" by looking into the directory project1/tags/1.0.5. The way we
handle deployment to our live server (which is a separate machine
from our development server) is that we have a working copy of the
previous release tag (say, 1.0.5) on the live server. Then, when the
time comes to upgrade to, say, 1.0.6, we SSH to the live server and
svn switch the working copy to project1/tags/1.0.6. This updates the
working copy to 1.0.6, and because it only transfers over the network
the differences between 1.0.5 and 1.0.6, it's quick and conserves
bandwidth.
You could have your live web server pointing to this working copy,
and add some web server directives to prevent web visitors from
descending into the .svn directories (because that would be a
security risk). But updates of a working copy are not atomic: if the
network connection were to go away in the middle of the svn switch,
the working copy would have some files from 1.0.6 and other files
still from 1.0.5. The web site would possibly not function in this
mixed state. Therefore, we have an extra layer: once the working copy
has been successfully switched, we export it to another directory,
and give that directory the same name as the tag, so in this case
1.0.6. From the previous version, there is also an export called
1.0.5. There is also a symlink called live, pointing at 1.0.5. The
web server is configured to serve files from "live". So, to switch
the site to the new version, all we have to do now is "rm -f live &&
ln -s 1.0.6 live". If we discover that 1.0.6 is broken and we need to
revert to 1.0.5 in a hurry, that's simply "rm -f live && ln -s 1.0.5
live". Once a version is sufficiently old that we won't need to
revert to it, we delete its export directory.
Yes, the working copy plus the exports do take many times the disk
space that just a single copy of your site would take. But we manage
our own server with a nice RAID 5 array, so in this case we subscribe
to the Subversion team's idea that disk space is plentiful and
therefore not a concern. If your site is large and your disk space is
not, a different strategy may be necessary.
Going a different way, you could do it without tagging each release
and instead have trunk, where all development takes place, and a
single release branch, to which all changes are merged when they're
supposed to be released. A post-commit hook could then update a
working copy on the development machine, export this to a new
temporary directory, and rsync that with an existing directory on the
live server. This would use less disk space on the live server, since
there would be just a single copy of the site and no working copy. It
would be susceptible to problems if the network connection were to go
away in the middle of an rsync, and it would be slower to revert to a
previous version if necessary. My gut feeling is also that I don't
like this method because it seems likely to me that some change on
trunk would get forgotten and never merged to the release branch,
which wouldn't do anybody any good. I've not spent much time thinking
of this method, since we haven't had to use it.
I've answered this a couple times already.... maybe it's time for
something to be added to the FAQ? I guess that means I'm supposed to
provide a patch.... :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jun 25 22:35:04 2005