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.
>
> 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.
>
> 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.
>
> Did anyone try something similar already? Any suggestions, estimates
> if this would work or not and why?
we came to the same solution more or less. we skipped our production
branch, and now deploy latest (HEAD) code to our development/test
machines and deploy from a well-defined list like yours to the
staging/production machines. the developers wont need to check out the
exact revision of a file/directory. we do a complete production "tag"
(svn copy) based on the list when deploying towards production. if they
really want to see what's in production they can checkout or export (but
not check in) that tag.
i'm not 100% happy with this solution, but it does seem to work.
./allan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 10 21:25:22 2006