On Feb 10, 2006, at 3:55 AM, Tilmann Singer wrote:
> Hello List,
>
> I would like to set up an environment for website development where
> most of the time the development happens on trunk and developers can
> flag individual files as ready for a staging server or ready for
> deployment on the production server.
>
> This kind of problem has been discussed before here
> http://svn.haxx.se/users/archive-2004-12/0824.shtml
> http://svn.haxx.se/users/archive-2004-12/1420.shtml
> but I couldn't find an answer to my specific question.
>
> In CVS it was easily possible to set a tag for 'staging' and
> 'production'. For example when a certain subdirectory of a working
> copy of the code was ready for staging, one could cd to that
> subdirectory in the working copy and do a "cvs tag 'staging'" to
> promote the staging tag for only the files within that subdirectory. I
> want to be able to do that only for specific subdirectories or files,
> without affecting other areas of the project, because there might be
> experimental development going on by me or other developers that is
> not yet ready for staging or production.
>
> One possibility to achieve this functionality in subversion would be
> to use one branch for production and one for staging, but in my
> understanding it would require to manually merge desired changesets
> into those two branches each time one wants to move a change into
> staging or production, and tracking somehow which changesets have
> already been merged. It implies the danger of forgetting to merge a
> changeset. My gut feeling to this approach is that it would become
> somehow messy, and too much administration for our limited resources
> and svn experience.
I think you should actually use a production and staging branch. To
help keep administrative burden down, use the svnmerge.py tool which
is distributed with Subversion. This will automatically keep track
of which revisions you've already merged over and which revisions are
available to be merged. It's a great way of cherry-picking revisions.
svnmerge.py keeps track of the already merged revisions in your
branch by modifying the svnmerge-integrated property on the
destination directory of the merge.
> So I had the idea to replicate the cvs tag functionality in the
> following way:
>
> Create a special file for each tag, deploy_list.staging and
> deploy_list.production, which control the revisions to be
> deployed. Each line in those directories contains a path below trunk
> and the associated revision. For example it could look like this:
>
> / 251
> /some_sub_dir/ 275
> /other_sub_dir/ 289
> /some/special/file.php 311
>
> Based on the contents of such a file I wrote a simple script that
> produces a svn export with the specified revisions for deployment on
> the staging and production server. It sorts the entries so that the
> least specific are exported first and proceeds to export the more
> specific. Before doing an svn export for an entry it does 'rm -rf' on
> that path to make sure that file deletes in the later version are
> being correctly exported.
That's a lot of work. The svnmerge.py will manage this for you much
easier. It'll be a single command:
svnmerge.py merge -r 534,537-539,540
svn commit -F svnmerge-commit-message.txt
I also recommend keeping the staging and production areas served by
your web server as Subversion working copies. That makes it easy to
roll back to a previous revision in case there was a problem missing
in the staging area that got into production. You would just run an
'svn update -r N' where N < HEAD and you would be back running on a
good release. With the file based solution, you would have a tough
time rolling back.
The only thing to watch out for is to prevent the .svn directories
from being served.
> The developers will have to use svn info to find out what version
> their local checkout is at and edit the deploy_list files to tag their
> changes as staging or production ready. I think that this will be less
> tedious and less dangerous than dealing with branches. Experience will
> show how it works out.
This sounds much more tedious :)
>
> Did anyone try something similar already? Any suggestions, estimates
> if this would work or not and why?
As an aside, my suggestion is to try to work with the way Subversion
does things and not to try to pull in the CVS model of working, which
become more painful.
Regards,
Blair
--
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
<blair@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Feb 12 03:41:27 2006