2

I'm taking steps to prevent someone (i.e. me) accidentally wiping the production server out.

I'm currently looking at SVN. I'm concerned that someone could accidentally issue the svn update command without specifying any files to update, and hence update the entire codebase to the head version.

Is there a way to prevent this from happening? Perhaps make svn an alias for a little pass-through script that checks inputs?

(I've already set up an alias for rm, to prevent people removing more than three files at a time, without seeing a confirmation prompt: alias rm='rm -I'. Are there any other little tweaks people make to their production servers, to reduce the risk of accidental catastrophe?)

Improve this question
3
  • I think your biggest problem is culture; how often are people logging into and getting access to a prod environment?
    – vcsjones
    Jun 29, 2011 at 17:00
  • Too often, true. But even if I locked it down, I want to prevent myself from making these mistakes.
    – aidan
    Jun 29, 2011 at 17:04
  • 3
    Maybe use exports instead of working copies for your production code, to prevent direct svn ups completely?
    – Shane Madden
    Jun 29, 2011 at 17:12

1 Answer 1

Reset to default
4

Use tags for your production environment. Always tag your releases, verify those tags in a testing environment (including that they have only the changes you actually want), then use the svn switch (aka svn sw) command on the production server to "update" to that tag.

In this way an accidental svn up won't affect anything (provided you're following best practices and not developing in your tags...).

"Spot fixes" -- i.e. quick bug fixes that need to go into production now -- can be done by making the fix in trunk, copying the current production tag to a new tag, then merging the fix from trunk into the tag; then use the same svn sw command to bring production up to that tag.

Also, @Shane's comment to use svn export instead (exporting your tag) is a good one, as it guarantees that you won't be leaking revision history data through the .svn folders on your web server. Your promotion process would then consist of exporting the tag to a new (empty) folder, then doing a quick switcheroo by renaming the current production folder to something else, and then renaming the "staging" folder to the name for the production folder. For example, in Linux, it would look like this:

mkdir staging
svn export http://www.example.com/path/to/your/tag staging/
mv production/ production-old/ && mv staging/ production/

Downside to this approach is that you can't use e.g. svn info to find out what tag production is currently on, but if you have good policies and follow good practices you should have this information handy -- and it should be accurate -- anyway.

Improve this answer
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .