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
Received on Thu Mar 15 00:04:37 2007