RE: Re: Using subversion for webdevelopment

I don't really see what this has to do with Subversion -- you're asking
"how can I have my users deploy to a test/production server" and SVN
answers the question "How do I keep track of the changes in my files".

I think in your case I would write a simple script (using shell, Ant,
perl, python, whatever is convenient) to deploy the files. Then your
web developer can run, for example, "ant deploy-test" to deploy to your
test server. When she's ready to commit those changes, then commit them
to SVN.

I mean, you could do something complicated, like having a branch in SVN
for each server, and then deploying to that server with a post-commit
hook and svn export. But if you want to avoid a commit to SVN for each
typo, mistake, etc., then I think you're not looking at the right tool
to accomplish your goal.

- Geoff

-----Original Message-----
From: Steven Vasilogianis [mailto:svasilogiani@kmrrec.org]
Sent: Tuesday, August 03, 2004 11:47 AM
To: Patrick Smears
Cc: users@subversion.tigris.org
Subject: Re: Using subversion for webdevelopment

[Sorry for sending this to you twice, Patrick. I meant to send it to the

group
as well.]

Patrick Smears wrote:

>> We have three servers, one for development, one for testing, and one
>> for production, and I like this setup. It would be impractical for
>> each of us to have a local development server setup, because it would
>> be way too much maintenance, and not everyone is capable of setting
it >> up (e.g., our designer). >> >> I also think it's impractical
for us to have to first commit our >> changes to the repository, and
then go to the development server and >> check out those changes in
order to test them. >> >> I suppose one solution might be to use a
post-commit hook which checks >> the repository out on our development
server, but how would I do this >> securely? >> >> So, how is this
typically handled?

> Just a thought: one possibility would be to create a virtual host for

each
> developer on the development server - that way, Fred can test his
changes at
> http://fred.internal.example.com, whereas Jim would access
> http://jim.internal.example.com, where both are serviced by the same
> physical server. This way there is only one central configuration
file (so
> one person can manage it - and keep all the hosts in sync), but it
provides
> some isolation, allowing one developer to break things without >
inconveniencing everyone else...

I think you've misinterpreted my problem; I probably didn't do a very
good job explaining it. (Although, being able to isolate peoples
mistakes is nice as well, so I'll look into your suggestion.)

$ svn checkout http://example.org/svn/some-site
$ emacs some-site/htdocs/index.php
[make some changes]
$ svn commit some-site/htdocs/index.php

Now, in order to test/view/whatever, those changes, they need to some
how get onto our development web server.

One way for me to do this is to ssh into our development server and do a
checkout. But it would become very frustrating to have to do this to fix
and test every minor bugfix and spelling mistake. Also, I would like to
avoid having to teach our designer to ssh in checkout changes. (There is
no way she would be willing to do this for every change. As it is, she
hates having to upload both an html and a css file.)

Thanks,

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