@wildcard99
In my opinion, it IS a VERY practical thing to use a version control system for *any* kind of development. The benefits that a version control system gives you are much more than simple backups - you get logs on when and why you changed something, diffs between versions, easy collaboration with someone should the project becomes something more than a one man solution/experiment. You will thank yourself for having the foresight to use a VC in only a week or so 😊.
That said, if you have not messed up with subversion before, I would not recommend it to you.
The overhead of this particular VC system is too high when you develop alone and want to just test a little hack. This is because you need a sysadmin that have alreade set up a Subversion repository somewhere. There are many things that can go wrong if you do not have the experience to do it. Especially if you are new and still unexperienced with the process.
In case you still want to go this way - you can try this http://lifehacker.com/software/subversion/hack-attack-how-to-set-up-a-personal-home-subversion-server-188582.php (it is a reasonably short and tested way to setup a private subversion repository server under windows), or try this http://www.howtoforge.com/debian_subversion_websvn if you are a debian linux user. There are also free SVN repositories online, but you will have to had a really fast connection, since SVN contacts the central repository for most history related operations (svn log and so on).
Since the title of the thread is “Version Control System” and not just “The subversion VCS” 😉, here goes a little personal rant - for 6 months I’ve been a commited and happy GIT user 😊 . It is much better than SVN at many things :
1) sheer SPEED, because you have a local repository and you use it for 90%-100% of GIT operations
2) support for easy last commit ammending : if you happen to change your mind about what goes in the last commit that you made (it is amazing how many times this little feature is useful) - this allows you to have better commit changeset and description messages, so the log of the changes becomes more useful ...
3) GIT has support for distributed development with much better merging and conflict resolution than SVN ever had, so it will scale better when/if you decide to have several people work on your project.
The only drawback so far is that (at least for now), there is not a client comparable with the nice integration of TortoiseSVN for Windows (well, may be I do not know if such a beast exists, please, correct me if it does).
That said, the GIT’s command line integration is much better than subversion’s, and the commands that you need in your typical development scenario are few:
“git init” at your project root to setup the GIT repo.
“git add FILE/FOLDER” to add a changed folder to GIT knowledge.
“git commit -m ‘Description of the change’” to commit your changes.
“git checkout HEAD” to revert changes to the last commit, HEAD^ will revert the last commit, HEAD^^ will revert the last 2 commits and so on.
“git log” to see a log of the changes so far.
“git status” to see the status of your project from GIT perspective - what has been changed but still not commited, what is still not version controlled and so on.
Basically, these commands are used 95% of the time, and picking up the rest is very easy since there is extensive console and online documentation, with common use cases and so on.