Gotchas

Don't ever submit a log without a description or corresponding bug number (if applicable) -- blank changelogs should not happen
Talk to your team
- Don't duplicate effort
- Be aware of other patches in progress
- Talk to each other to ensure that your patches won't cause regressions
- Run the usual smoke tests and (ideally) some sort of automated script that can spot SNAFUs immediately
Don't file IT requests for production updates every hour, and don't email them every 5 minutes (or text-message them either) -- your best bet is to group your updates and push them weekly.

Examples

Examples on this page assume:
- You're using the command line client over ssh
- You're editing the mozilla.com site - modify as necessary
- You're familiar with SVN, (or at least have read our Introduction)

Staging and production are as close to the same thing as we can make them.
- If production is using vhost blocks in a .conf, staging should too
- Code for both should always be from the same production tag.
- (Programmers should be developing and testing on their own branches, or /trunk/)

Basic process is: check out production, merge your changes, commit production
Our example assumes:
- All patches are done and checked into trunk
- You've checked out svn+ssh://svn.mozilla.org/projects/mozilla.com/tags/production to /data/mozilla.com
- The last revision of the production tag is revision 100. This can be found by running `svn info` in /data/mozilla.com/ and looking at the "Last Changed Rev:" line
- The last revision of the trunk is 150. We're using a number here instead of HEAD to avoid having someone commit while you're in the middle of these steps and mess things up
From the production tag's directory, merge the changes (If you'd like to see what's going to change without actually changing it, add --dry-run)

[clouserw@fattony /data/mozilla.com]$ svn merge -r 100:150 svn+ssh://svn.mozilla.org/projects/mozilla.com/trunk

[clouserw@fattony /data/mozilla.com]$ svn diff -r 100

When you're SURE that the patches are correct/make sense, you need to commit it (substitute your rev # for 150):

[clouserw@fattony /data/mozilla.com]$ svn commit -m "Merging revisions 100:150 /trunk/ into /tags/production/"

Only initiate a request if you are sure you are not causing a serious regression
For major updates, you should contact major parties and discuss the update -- at least briefly -- so they are aware. When in doubt, just email everyone. :)

File an IT Request when you are sure you are ready to go
Include in the request the revision number of the previous merge, so an easy rollback can occur! Also include any other rollback instructions. You can get the previous revision number by running `svn log` on the production tag.
Assign the appropriate severity -- note that critical or blocker pages the oncall.

Updating production should be a simple step, and should always be consistent if we follow this procedure:

[root@do-stage01]$ svn up

Note: If configuration or db changes are required, specify the order and the action in the request bug
Please paste the last line of output into the bug (Should be something like "Updated to revision 15")

Always be available after updates are pushed
Tell the community you have made an update -- blog, planet, etc.
Keep an eye open for what's going on, file an IT request or page sysadmin for a rollback if necessary

[root@do-stage01]$ cd /data/live/www.mozilla.com/
[root@do-stage01]$ svn switch -r 100 svn+ssh://svn.mozilla.org/projects/mozilla.com/tags/production

[root@do-stage01]$ cd /data/live/www.mozilla.com/
[root@do-stage01]$ svn log

When rolling back, don't forget any database/config changes that need to be rolled back