We have a small team, and we let the developers be responsible for checking things into the proper locations. We generally check in small changes directly to trunk, and they almost immediatelly get deployed to production (by me). For larger changes, a tag gets created as well as a branch and a trac ticket. Let's say the ticket number is 5. We would copy trunk to tags/pre-t5 and then to branches/t5. The developer then switches his working copy to branches/t5 and does his changes. Whenever he is done, the changes are merged into a qa environment, and once tested and ready to go, they get committed to the trunk and deployed to production.
I am the only one who does deployments, so I can keepb an eye on things. If I don't want developers committing things to the trunk, I can set up their permissions to disallow them doing so.
Hope this helps,
Russ
Sent wirelessly via BlackBerry from T-Mobile.
-----Original Message-----
From: Jim Thompson <jim.thompson@doit.wisc.edu>
Date: Fri, 26 Jan 2007 09:50:53
To:rsivak@istandfor.com
Cc:Janine Sisk <janine@furfly.net>, Subversion List <users@subversion.tigris.org>
Subject: Re: Pushing asynchronous changes to production
Russ,
Just curious - do you have a way to enforce this?
> nothing _should_ be in trunk that's not ready to go on prd.
We're coming from CVS, where we use the taginfo filter. We let regular
developers commit anything they wish and they can tag files "test"
and/or "testdemo". Only certain folks (not developers) are allowed to
manipulate qa, prod or demo tags. We also have more tags that are
maintained by scripts. Then we have tags for our framework (vs. app)
files - currently 7 different environments. Config files sometimes have
up to 8 branches.
Cheers,
Jim
Russ wrote:
>We develop Websites too and use svn. Production is just a checkout of trunk, and nothing should be in trunk that's not ready to go on prd.
>
>You can btw update individual files at least with TortoiseSVN.
>
>Russ
>Sent wirelessly via BlackBerry from T-Mobile.
>
>-----Original Message-----
>From: Janine Sisk <janine@furfly.net>
>Date: Thu, 25 Jan 2007 16:12:49
>To:Subversion List <users@subversion.tigris.org>
>Subject: Pushing asynchronous changes to production
>
>I found a few people asking this question, and could probably have
>found more if I'd known the right keywords to use, but didn't find
>any really satisfying answers.
>
>We have a fairly typical development/production website setup. Under
>CVS we tagged the files that were ready to go to production with
>"stable", and then (because the production site was created via a
>checkout on the stable tag initially) used cvs update to move them to
>production. This is easily scripted for the less technical user, and
>has worked well for us. Each person can move only their changes
>without knowing or caring if someone else has checkpointed their work
>by committing but is not ready to go live with it yet.
>
>The question is how to emulate this setup in svn. It's not possible
>to tag only the commits you want moved to production anymore, and
>making a branch for every little change is not very practical.
>
>One person suggested passing a filename and revision number to a
>script that would update the file to that revision, but as far as I
>can tell "svn update" doesn't take filenames, only directories, so
>I"m not sure how to do that.
>
>I know there are many home-grown solutions to this problem out there,
>and I'd love to hear about them, but it seems there should be a
>recommended way to handle it and I haven't been able to find it, if
>it exists.
>
>thanks,
>
>janine
>
>---------------------------------------------------------------------
>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
Received on Fri Jan 26 17:37:24 2007