svn enabled for a remote website

[Todd Eddy <vr...@neo.rr.com>]

Here's another "think tank" situation.

Ever since I've started to look at svn I've thought about making my 
website svn enabled.  Here are the issues though:

- website is hosted on a shared hosting plan, so can't install svn on 
that server (probably could with enough hacking, but don't want the 
limited ammount of space on have there eaten up by svn.
- svn is on the local network here on a computer that is connected 
24/7 to an allways on internet connection.
- when modifing pages, I want to see the changes immediately if I 
mess up something
- there were others that I can't think of right now

I've though of a couple ideas for this.  Now this first one uses the 
idea that you can pretty much read straight from the repository 
folder without problems, which it sounds like you can.  I would set 
up an rsync connection between my computer here and the hosts server. 
 when I start to modify stuff, I run a script that runs it every 1 or 
2 minutes.  Won't be that big of a deal since it only uploads what 
changes, so most of the time it won't be doing anything.  But I would 
commit the changed file to the repository, which would then get on 
the website within a couple minutes, which is an acceptable ammount 
of time to wait.

The other method, which I would probably end up doing if I decide to 
do it, is basically keeping the two separate.  I would make changes 
and upload them to the site, if it works right I'll commit the file 
to the repository.  Plus this would allow me to not have to put 
everything in svn, and put all the items I do want to track in svn.  
My main area of concern is the "reference" section, which has 
writeups I do on various topics (working on a detailed how-to install 
svn) and then maybe the section with all my style sheets and includes 
and stuff.  Neither area gets updated too frequently, so this upload 
and then commit version would probably be more ideal in a situation 
like this.

I know there is an svn powered wiki script out there, but I'm still 
going to be the only person that adds or modifies files.  I'm not 
even sure if I'm going to do it, mainly just going to use svn for the 
scripts I'm going to be making, not for web pages.  This is just sort 
of an after-thought thing that I thought some people would like to 
brainstorm about if your waiting to get out of work friday :)
-- 
Todd Eddy
vrillusions@neo.rr.com
www.vrillusions.com


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: svn enabled for a remote website

[John Peacock <jp...@rowman.com>]

Todd Eddy wrote:

> - website is hosted on a shared hosting plan, so can't install svn on 
> that server (probably could with enough hacking, but don't want the 
> limited ammount of space on have there eaten up by svn.

You should differentiate between the svn repository (and the associated 
processes needed to access it) and the svn client only.  The client only isn't 
that bad.

> - svn is on the local network here on a computer that is connected 
> 24/7 to an allways on internet connection.

This is your svn repository/server, then.

> - when modifing pages, I want to see the changes immediately if I 
> mess up something

Not cool on a production site! YMMV

What I am in the process of setting up in subversion is exactly what I am doing 
now with CVSNT:

1) Test server contains both the web sites and the subversion repository, with a 
post-commit trigger to keep the web sites up to date;

2) Production server contains client only and is updated manually (after testing).

This works great now with CVSNT (recent versions have a post-commit hook) with 
multiple developers.  Another advantage to this scheme is that the test server 
can actually keep a branch checked out for major updates, while the production 
server is still on the trunk (or vice versa).  A quick 'svn switch' can move 
either to a different branch for testing or deployment.  I can even make 
corrections to the production site (by switching the trunk) and then return to 
the major update (by switching back to the branch).

The one thing I would like to try is to serve the test site directly from the 
repository (without a WC), but I haven't had to time to test that...

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org