SVN just stores and distributes code. It doesn't run the code. It's main benefits are you have a history of all changes, it helps to synchronize those changes with other people you might be working with, and by default you have a remote copy stored on some other computer so you don't lose everything if your harddrive crashes.
The history tracking and remote backup benefits are more than enough to convince me to store all my projects in some kind of version control system, such as SVN. The network distribution of code really shines though if you're working with other people, or even if you just have multiple development machines. If you need to switch to a different computer, or get a code update that someone else pushed, it takes a whole two clicks to update a working copy. You can be up and running on a new machine in no time, and you don't even need any pre-planning, such as zipping up your code to transfer to a new computer.
Version control systems make passing around of zip files incredibly antiquated. If you've ever tried working in parallel with someone else on the same project, you'll find that passing zip files back and forth doesn't scale well. Having two people work on two separate features at the same time for the same project is really easy with a good version control system though. Basically: You make and test changes for the feature you're working on, and commit those changes to the repository. Then you email, instant message, or shout over the cubicle wall telling the other person to update. Then continue working on your next feature. When they've committed changes and tell you to update, you just run an update and their changes are merged into what you're working on.
Some more detail: With TortoiseSVN, you commit by right-clicking on the project folder in Windows Explorer (not Internet Explorer), and choosing commit. You type a quick commit log message that summarizes the changes your making, and then those changes are sent to the server. It actually only sends a diff of what you've changed since your last update, so if you change one byte in a 1GB file, the commit will only describe that 1 byte that changed, so you don't need to send a full 1GB to the server. Similarly, when you update, you only get a diff of what changed since your last update. So if someone made a 1 byte change to a 1GB file, you don't need to download the whole thing again, you just get a description of that 1 byte change.
And of course if you don't like any particular change, having complete history and built in revert capability means you can undo changes quite easily. Ever gotten an hour or two into a big long change that breaks your code base before you realize there's a better way, or that your whole plan was flawed and isn't going to work? That moment right there sure makes you appreciate the concept of history.
