SVN best practice #1: Check status before updating!

I maintain several websites as Subversion Checkouts.  I’ve had great luck with this as long as everyone on my team follows a few rules, and I thought I’d start saving & sharing some of them here.  This brief article explains the use of a couple of key SVN commands.

One of the things I’ve gotten in the habit of lately is to check the version of each and every file that I’m about to update whenever I do a big server update like we did last night for a busy website.  In this case it was VERY helpful to have done-so because I accidentally released a new beta version of  a few files that our client hadn’t approved yet.  Since I have the ‘list’ of all files that I’ve changed it’s quite easy to revert a few if necessary.  It works very well.

In brief, here’s what you do:
Before any update, check the status of all files with this svn command:
svn status -u
The status command with the -u option tells SVN to go compare everything locally to what’s in the repository.  You get output like this:
    *   3362   new_feature/feature.msi
    *   3362   new_feature/feature.exe

Any file with a * will be updated if you perform an SVN update, but it also tells you what version you’re currently on.  Then I updated my website to v3450 (including the not-ready-for-prime-time files).  Once I realized my error it was a simple matter to do an svn update to a revision as follows:

svn up -r3362

I performed this update right inside the ‘not-ready-for-prime-time’ folder and it caused these files to update back to the revision closest to 3362.  BAM!  Done and Done.  Note that this update-to-revision is not sticky, so I’ll have to be careful if I update the server again before these particular files are approved.  Also, note that I’ve ignored another best-practice here which is that I should have had my developer put this beta area on a branch, which would have avoided this issue all-together; but that is a topic for another post.

SVN Status can also tell you other important information, here are a couple cases:
?             feature.back
The ? lets you know that this file hasn’t ever been checked in to SVN.
M   *  3362   help.php
this file has been Modified (M) locally without being checked in AND is modified (*) in SVN.  Watch out for potential conflicts!

I really, really don’t like to have me or my programmers editing files right on the production server except in dire circumstances, so I usually go have a talk with someone about it whenever I find these types of entries.  I also make sure to clean them up right away once I notice them.

Anyway, I hope you found this helpful.

Posted by Greg on October 17th, 2011 :: Filed under Subversion,Tips
You can leave a response, or trackback from your own site.

Leave a Reply

Type your comment in the box below: