So I've recently spoken to some old colleagues about how they use SVN to release their site code and realized that there is still not a lot of common use of a release process. They suffer due to their time constraints since they've had little time to review and it can be daunting to take on the task of redefining a new aproach to this technology if you're really crunched for time. On the other hand, it can also be very nerve wracking when you're pushing code by updating a folder because if there's an issue a code roll-back is manual. I've been shown a solution to this challenge myself so I thought it would be good to put up an article giving an easy straight forward way for you to upgrade your approach without too much difficulty. If you can't retrofit your project in the way I'll show, you should be able to at least find another way once you understand the principles behind it.
So here's a sample site with a releases folder and a website folder.
Once you've made all the changes and commits to the website and you feel it's a stable release, then right-click on the "website" folder and select "copy to…". You're going to make a "light-copy" of the website folder. This is just a copy that copies all the version numbers not the actual files. Although if you check out the release folder you will get files, but SVN doesn't duplicate them in its system. What we're doing here is taking a snapshot of your site and storing that so that we can jump between snapshots later.
Select the releases folder and give it a name like "1.0" or "1.0.0" depending on how granular you want to be with your releases
Then you'll leave a note detailing the changes for the release.
Now in the SVN content tree you'll see the folder is a copy of the website folder. Again it's really just a snapshot of the state the website folder was in at that time.
Now for the initial checkout you'll want to checkout this first release. So go to the folder where you want to deploy this website and Right-click->Tortoise SVN->Checkout. Select the 1.0 folder and place it where you want it to end up and click ok.
Over time you'll end up making more changes to your site and committing those changes and then get to a point where you're ready to release this new code. You'll go through the previous steps of creating another release copy. Here it's named "1.1" to as you would expect.
Following the steps previously detailed we'll make a note about the functionality that has changed.
This time though instead of checking out the copy since it's already checked out, you can do a Right-click->Tortoise SVN->Switch.
This will detect the differences between the branches and will just change those differences. If there are any collisions, which happens rarely in my experience, you can just delete the contents of the folder and checkout the folder you're targeting. In this case it would be the "1.1" folder. Here you'll be presented with a dialog window and you can clear the current folder and click on the browse button to select the version you want.
You'll get a tree view and you can select the new targeted version and click ok.
You'll then be presented with the changes just like you would when you do an update or a merge.
That's it. Now let's say that change you've made caused a major issue. You'll be able to run a switch and change back to the previous version very quickly and most importantly, automatically. This little nugget will save you a lot of headaches and time should you get into a pinch, but you'll never need it since all the code you write never has an issue, right? I'm sure, but just in case now you've got a backup plan.