On Wednesday 14 March 2007 16:13, matt farey wrote:
> Ivan Aleman wrote:
> > 2007/3/14, Mike Brenner <mikeb@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
Received on Tue Apr 3 18:35:57 2007