You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by matt farey <ma...@gmail.com> on 2007/03/14 14:09:50 UTC
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
Re: code release cycle under svn
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 30, 2007, at 06:42, Greg Rundlett wrote:
> Using a working copy on the production server *is* the best
> approach, which I
> call the 'pull' approach. You pull updates using svn update. Have
> a problem
> in production? you instantly revert changes using svn switch -r PREV.
Note that svn update is not an atomic operation. From the time that
you issue the svn update command until the time that it completes
successfully, your web site is potentially in an inconsistent state
and, depending on how it's programmed and the changes that will occur
in the to-be-retrieved revisions, may not function properly. Note
also that if a network problem occurs during the svn update
operation, it may exit with an error, leaving the web site in an
inconsistent state until you successfully complete svn update.
For these reasons I prefer to keep a working copy on the server, but
not point Apache's document root directly to it. Rather, once the
update completes, I svn export the working copy to a new directory,
whose name is unique (could be based on the revision number, for
example, which you can find using svnversion). I also have a symlink
with a name like "current" which I relink to the newly created export
directory (ln -sf export-r1234 current). Apache's document root
points at the "current" symlink. Then old exported directories can be
deleted to free up disk space, if desired. Or the last one or two can
be kept around, in case of a need to roll the web site back to a
previous version -- instead of having to wait for an svn up -r PREV
to complete, you can simply relink "current" back to the previously
exported directory.
--
To reply to the mailing list, please use your mailer's Reply To All
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: code release cycle under svn
Posted by Greg Rundlett <gr...@oasis-open.org>.
On Wednesday 14 March 2007 16:13, matt farey wrote:
> Ivan Aleman wrote:
> > 2007/3/14, Mike Brenner <mi...@mitre.org>:
> >> Hi Ivan,
> >>
> >> I don't think svn will push the files, I think the
> >> web server needs to pull the files from svn.
> >
> > Hello Mike, you're right I think I misunderstood what Matt was asking,
> > indeed my answer was oriented to how layout a repository as
> > recommended in the book and push the files to production server using
> > the files that are tagged as a release under 'tags' branch. And of
> > course you can pull a working copy or better a 'tag' copy from
> > production server to start and upload the first time this is fine
> > still I think is prone to errors.
> >
> > The way I do it? I first tag the release and copy to tags branch then
> > I checkout to the tag and because we have some misc folders and files
> > that aren't needed in production I remove those and all the SQL
> > scripts, etc, then I strip out the .svn info/tracking folders and
> > tar.bz2 the root folder of the tag and push the compressed file trough
> > VPN... et voila! Every time a new release is available I do the same
> > steps of course I use a 'maintenance' screen and if something needs to
> > be changed quickly but the change was not int he tag/release I push
> > the file or files from trunk branch using the VPN and SSH that's it,
> > this is more common to me 'cause releases under tags take longer to
> > occur, so I push lets say version 1.0.0 then the natural thing is to
> > correct mistakes/bugs that weren't detected on development time so you
> > can see every push as 1.0.1, 1.0.5, 1.2.0, etc until it stops for a
> > while and a new release appears, so it's time to start over.
>
> I obviously have a lot to read, which I shall do tonight, thank you Ivan
> and Mike for your responses. I shall reorganise my repo, and attempt to
> do excatly as you say, and get back to you tomorrow. At the moment I
> feel a bit idiotic as my working copy _is_ the web server source, I have
> been committing any changes to the repo, and updating any changes made
> by others into the web doc tree.
> It would be nice to get away from this, and have the ability to simply
> pull (not push as you say) a "release" onto the web server, and work
> like the others do, on a working set somewhere else!!
> thank you again.
Using a working copy on the production server *is* the best approach, which I
call the 'pull' approach. You pull updates using svn update. Have a problem
in production? you instantly revert changes using svn switch -r PREV.
Using working copies to serve websites works all the way up the line from
production (end of the line) to staging, development, and localhost
(individual developer). It also makes it easy to put one particular branch
or tag on a staging server for Q/A to determine if that code can be merged
into trunk.
I've done a lot of 'push' using deft and complex rsync commands to move a
working copy down the line, and know that there is a lot more work, with less
flexibility in that approach.
-- freephile
>
> > That's the way I do it I am sure there are other better ways to handle
> > this using rsync or something else, may somebody explain here the way
> > they do it and consider their method as a better practice :) I will
> > appreciate it.
> >
> >
> >
> >
> >
> > Kind regards.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: code release cycle under svn
Posted by matt farey <ma...@gmail.com>.
Ivan Aleman wrote:
> 2007/3/14, Mike Brenner <mi...@mitre.org>:
>> Hi Ivan,
>>
>> I don't think svn will push the files, I think the
>> web server needs to pull the files from svn.
>>
> Hello Mike, you're right I think I misunderstood what Matt was asking,
> indeed my answer was oriented to how layout a repository as
> recommended in the book and push the files to production server using
> the files that are tagged as a release under 'tags' branch. And of
> course you can pull a working copy or better a 'tag' copy from
> production server to start and upload the first time this is fine
> still I think is prone to errors.
>
> The way I do it? I first tag the release and copy to tags branch then
> I checkout to the tag and because we have some misc folders and files
> that aren't needed in production I remove those and all the SQL
> scripts, etc, then I strip out the .svn info/tracking folders and
> tar.bz2 the root folder of the tag and push the compressed file trough
> VPN... et voila! Every time a new release is available I do the same
> steps of course I use a 'maintenance' screen and if something needs to
> be changed quickly but the change was not int he tag/release I push
> the file or files from trunk branch using the VPN and SSH that's it,
> this is more common to me 'cause releases under tags take longer to
> occur, so I push lets say version 1.0.0 then the natural thing is to
> correct mistakes/bugs that weren't detected on development time so you
> can see every push as 1.0.1, 1.0.5, 1.2.0, etc until it stops for a
> while and a new release appears, so it's time to start over.
>
I obviously have a lot to read, which I shall do tonight, thank you Ivan
and Mike for your responses. I shall reorganise my repo, and attempt to
do excatly as you say, and get back to you tomorrow. At the moment I
feel a bit idiotic as my working copy _is_ the web server source, I have
been committing any changes to the repo, and updating any changes made
by others into the web doc tree.
It would be nice to get away from this, and have the ability to simply
pull (not push as you say) a "release" onto the web server, and work
like the others do, on a working set somewhere else!!
thank you again.
> That's the way I do it I am sure there are other better ways to handle
> this using rsync or something else, may somebody explain here the way
> they do it and consider their method as a better practice :) I will
> appreciate it.
>
>>
>>
>>
> Kind regards.
>
--
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
Re: code release cycle under svn
Posted by Ivan Aleman <bo...@gmail.com>.
2007/3/14, Mike Brenner <mi...@mitre.org>:
> Hi Ivan,
>
> I don't think svn will push the files, I think the
> web server needs to pull the files from svn.
>
Hello Mike, you're right I think I misunderstood what Matt was asking,
indeed my answer was oriented to how layout a repository as
recommended in the book and push the files to production server using
the files that are tagged as a release under 'tags' branch. And of
course you can pull a working copy or better a 'tag' copy from
production server to start and upload the first time this is fine
still I think is prone to errors.
The way I do it? I first tag the release and copy to tags branch then
I checkout to the tag and because we have some misc folders and files
that aren't needed in production I remove those and all the SQL
scripts, etc, then I strip out the .svn info/tracking folders and
tar.bz2 the root folder of the tag and push the compressed file trough
VPN... et voila! Every time a new release is available I do the same
steps of course I use a 'maintenance' screen and if something needs to
be changed quickly but the change was not int he tag/release I push
the file or files from trunk branch using the VPN and SSH that's it,
this is more common to me 'cause releases under tags take longer to
occur, so I push lets say version 1.0.0 then the natural thing is to
correct mistakes/bugs that weren't detected on development time so you
can see every push as 1.0.1, 1.0.5, 1.2.0, etc until it stops for a
while and a new release appears, so it's time to start over.
That's the way I do it I am sure there are other better ways to handle
this using rsync or something else, may somebody explain here the way
they do it and consider their method as a better practice :) I will
appreciate it.
>
>
>
Kind regards.
--
Iván Alemán -- bonovoxmofo.blogspot.com
Cambia ya!
http://goodbye-microsoft.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: code release cycle under svn
Posted by Mike Brenner <mi...@mitre.org>.
Hi Ivan,
I don't think svn will push the files, I think the
web server needs to pull the files from svn.
In my web services a baseline takes several directories
(web server configuration files, sql files,
web applications, web services, documentation,
installation test programs, etc.). Svn can
check out the files with that directory structure,
if you have your server set up that way.
Since svn can check out all the directories underneath
any particular directory, you could create
a new directory for each baseline, then do an "svn co"
underneath the baseline's directory. You would have
to point your web configuration files to that
new subdirectory, of course.
Mike
Ivan Aleman wrote:
>> A web dev project ...
>> SVN to push a working set of files to the server ...
>> stage the release of the code to the web server ...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: code release cycle under svn
Posted by Ivan Aleman <bo...@gmail.com>.
2007/3/14, matt farey <ma...@gmail.com>:
> 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.
>
Hello Matt,
'Tags' brach is used for 'stable' releases read more about this branch
and the other involved on the svn book here's the link
http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.branchmerge.maint.layout
>
--
Iván Alemán -- bonovoxmofo.blogspot.com
Cambia ya!
http://goodbye-microsoft.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: code release cycle under svn
Posted by matt farey <ma...@gmail.com>.
Michael P. Reilly wrote:
> 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.
I did think about this, my cron will be monthly, and yes I would want to
have some way of setting the cron job to commit the last known good
tagged release. I will get to sign off the release before it goes up.
>
> 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.
Very good idea, yes I will use a new port, and use Order Allow,Deny and
Allow only from those who can authenticate as admins.
> And the cron jobs could be automatically be updating the staging server.
Yep that makes sense.
>
> But you want to verify the staging server before you flip a switch to
> push things out to production.
> -Arcege
Yes, a thorough code audit - the project makes heavy use of AJAX - which
gives me nebulous security kittens. (not a pretty picture)
Thanks Michael, good advice too.
> On 3/14/07, *matt farey* < matt.farey@gmail.com
> <ma...@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
> <ma...@gmail.com>]
> > Sent: Wednesday, March 14, 2007 7:10 AM
> > To: users@subversion.tigris.org <ma...@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/
> <http://www.webserver.com/www/trunk/private/>
> > www.webserver.com/www/trunk/public/
> <http://www.webserver.com/www/trunk/public/>
> > where
> > www.webserver.com/www/trunk/ <http://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
> <ma...@subversion.tigris.org>
> > For additional commands, e-mail:
> users-help@subversion.tigris.org
> <ma...@subversion.tigris.org>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> <ma...@subversion.tigris.org>
> > For additional commands, e-mail:
> users-help@subversion.tigris.org
> <ma...@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
> <ma...@subversion.tigris.org>
> For additional commands, e-mail: users-help@subversion.tigris.org
> <ma...@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.
--
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
Re: code release cycle under svn
Posted by "Michael P. Reilly" <ar...@gmail.com>.
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 <ma...@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.
RE: code release cycle under svn
Posted by Tech Support <Te...@wsas.com>.
Matt,
I know how you feel, I have never used a versioning software until
this month. But juggling production and development servers was getting to
bee too much for me. Svn has really helped my management of all my servers
and what is visible.
I am glad I could be of assistance.
Scott
-----Original Message-----
From: matt farey [mailto:matt.farey@gmail.com]
Sent: Wednesday, March 14, 2007 4:04 PM
To: users@subversion.tigris.org
Cc: Tech Support
Subject: Re: code release cycle under svn
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: code release cycle under svn
Posted by matt farey <ma...@gmail.com>.
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
RE: code release cycle under svn
Posted by Tech Support <Te...@wsas.com>.
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
-----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