I would strongly disagree with putting cron jobs that automatically update
the production environment.
First, you lose control of the production environment - if there is an
error, it is out there. Second, there is the need to either merge to the
same tag each release or have the cron understand which tag is current.
What is commonly done is to have a staging/preview area. Development would
get pushed to the staging server, changes are checked there before being
finally pushed to the production server. You could set the staging server up
on the same host as the production server by using a different port (8081,
for example), in case you are short on hardware. And the cron jobs could be
automatically be updating the staging server.
But you want to verify the staging server before you flip a switch to push
things out to production.
-Arcege
On 3/14/07, matt farey <matt.farey@gmail.com> wrote:
>
>
>
> Tech Support wrote:
> > Matt,
> >
> > The route I went, and this may help you, I setup a Directory for
> > development and one for production.
> >
> > The production servers I checked out a working copy of the production
> folder
> > where only the administrator has the ability to commit to. Then I set
> up a
> > crontab job to do a svn up every half hour this will keep the Production
> > servers current.
> >
> > I did the same with the development servers but the developers have
> commit
> > ability and the crontab is set to every min. this allows developers more
> > "Real Time" web developing environment and prevents users from updating
> the
> > Production systems.
> >
> > Hope this helps.
> >
> > Scott
> >
> >
>
> Thank you Scott, I will immediately set up said cron for the prod
> server, that makes a lot of sense.
> I was thinking along the lines of "its March of the 1st year of this
> stuff so I know that the prod server has release y=1 years and x=3
> months, 1.3 perhaps then bugfix n making 1.3.0n" so I can keep track
> transparently from outside SVN of what is emerging from it.
> I wondered what this would mean for the structure in the repository -
> would I see multiple directories,
> 1
> |_1
> |_00
> |_01
> |_02
> |_2
> |_00
> |_01
> .
> .
> .
> for releases 1.1 1.1 bugfix 1 bugfix 2 through release 1.2 in the second
> month bugfix 1 etc...
> I just get the impression with SVN that a seriously organised methodical
> and experienced approach can be helpful in mitigating disasters later.
> I've lurked on this list for long enough to see a few real nasties with
> no backup, I would like "built in roll back" where it doesnt just depend
> on being able to go back to revision 3411 of a single file, but I can
> switch directories. Then again I am probably over simplifying matters
> and due to the way the repo DB works I doubt there is replication with
> the DB anyway.
> You see I am such a newbie I am scared to do _anything_!!
>
> Thanks again, m
>
> > -----Original Message-----
> > From: matt farey [mailto:matt.farey@gmail.com]
> > Sent: Wednesday, March 14, 2007 7:10 AM
> > To: users@subversion.tigris.org
> > Subject: code release cycle under svn
> >
> > Hiya,
> > I've come late to SVN use, so I apologise if this question gives you a
> bored
> > sinking feeling!
> > A web dev project is getting increasingly complex, I would like to know
> how
> > to stage the release of the code to the web server, so that each month I
> can
> > use SVN to push a working set of files to the server delivering a
> > predictable code release cycle to the client.
> > I realise I could just commit (with note "release 1.0" in the log) from
> my
> > working copy, then from the server check out a particular revision into
> the
> > web root for that app, but was wondering if I could get some thoughts
> from
> > more experienced users. In major opensource releases I notice there are
> > often multiple directories corresponding to each new release, I like
> this
> > structure.
> > The project as a whole is only a few MB so I'm not too concerned about
> HD
> > space, what most concerns me is transparency, - I am still at the newbie
> -
> > "black box awe" stage of SVN use!
> >
> > At the moment the repo is organised like so:
> > www.webserver.com/www/trunk/private/
> > www.webserver.com/www/trunk/public/
> > where
> > www.webserver.com/www/trunk/
> > corresponds to the web doc root for the vhost concerned.
> > I realise this structure might have to change!
> > matt
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
> >
>
> --
> Matthew Farey
> Web App Sec.
> 25 The Polygon, Southampton, Hants, SO15 2BP, UK
> Phone +44(0)2380 631449
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
--
There's so many different worlds,
So many different suns.
And we have just one world,
But we live in different ones.
Received on Thu Mar 15 00:23:23 2007