Handling production code with source control, any better ideas?

suaveant has asked for the wisdom of the Perl Monks concerning the following question:

So, how to people manage living code under CVS? We have sandbox,dev,pre-prod,prod and disaster recovery systems all running Perl. In the past we would tag files for a release and then cvs upd -r tagname to bring the various systems up to date. This worked rather well, but the major downfall being when we need to make a fix we move the tag on the existing file (or occasionally branch if necessary). When moving a tag, however, you lose track of what was on prod before the tag is moved.

We're trying keeping prod on its own full branch but that causes issues as well. For one, merging onto the prod branch almost always causes conflicts (that we ignore), for two it is not exactly obvious how to handle reverting code if a delivery goes horribly wrong. We could use cvs's date updating but files are often on the ppe system days before they go out, and going by date won't give us the state of the prod server as it was on a certain day necessarily.

Other people must be working in situations like this, how do you handle keeping track of your production code in a living web application?

- Ant
- Some of my best work - (1 2 3)

Comment on Handling production code with source control, any better ideas?

Replies are listed 'Best First'.
Re: Handling production code with source control, any better ideas? by raybies (Chaplain) on Mar 16, 2011 at 19:02 UTC
Honestly, this is what branching is for, however branching (especially the merge back) in CVS is so cantankerous that pretty much everyone I know does their own branching rather than using the "automated" branching in cvs. IMO, one thing you might try is creating two tags, one as a snapshot tag associated with a date, the other being a sort of production tag that would be force-updated. The problem with that solution is that at some point you still have to worry about what your head revision really is... and I haven't thought that far ahead. Also, since the CVS repository, itself, is so easy to manipulate... I've also created my own snapshot of the repository itself, by just wholesale copying it into a different repository name. If you don't care about diskspace, and don't do it too often, that might be the easiest solution. --Ray	[reply]
Re: Handling production code with source control, any better ideas? by ELISHEVA (Prior) on Mar 16, 2011 at 18:08 UTC
We use subversion now, but back when we were using CVS, we always tagged releases with product_major_minor_patch. So instead of `cvs upd` with an existing tag we would take a current snapshot of the branch with `cvs tag`. Then we would export to the production environment by selecting files with the new release tag. That way we always knew what files went together even when we had to move files around for the next release.	[reply] [d/l] [select]
Re^2: Handling production code with source control, any better ideas? by suaveant (Parson) on Mar 16, 2011 at 20:48 UTC
We were all set to go to svn and then realized our existing tagging scheme failed miserably in svn, so we backed out. If we can get the branching working, or something else, we may yet switch. I can't wait to be able to change file permissions. - Ant - Some of my best work - (1 2 3)	[reply]