Why choose ? It should be both.
Your development environment should be configured so it's as easy as doing a checkout, open, build, run, debug (eg: no absolute path!). You can do that easily with compilation directives, configuration class + dependancy injection, or even tricks like the perso.config in ASP.NET
Your automated build script should be customized enought to take care of specific production configuration, clean up, packaging etc.
Software configuration management, of which Version Control is part, is a little more complex than keeping track of changes to files, although you can certainly start with that. But do read the Wikipedia articles linked above along with Joel Spolky's tutorial on Mercurial.
To start, choose one of Mercurial, GIT, or Bazaar, in that order, and install it along with tools for your IDE and operating system (I prefer Mercurial with HGE for Eclipse).
- Initialize a repository from your working directory (hg init with Mercurial)..
- Decide which files and directories you want to track and which not. The general rule is not to track files that are generated by compilers and other tools.
- Use the command to add the files and directories to the repository (hg add for Mercurial).
- Tell the tool about the patterns for the files you don't want to track (edit .hgignore for Mercurial).
- Perform a commit to track the original versions (hg ci).
- Perform a commit after each logical milestone, even if it's a small one.
- Add new files as you create them.
- Repeat the last two.
- Backup your working directory and the repository as frequently as reasonable.
With your files in the repository, you can know the differences between any two versions of a file or directory, or the complete project (hg diff), see the history of changes (hg hist), and roll back changes (hg up -r).
It is a good idea to tag (hg tag) the repository before publishing your code so there's an easy way of going back to exactly what you published for amendments or comparisons.
If you want to experiment with a different line of development, do it in a simple branch by cloning the main repository (hg clone) and not pushing back until the experiment is conclusive. It is as easy as having a different working directory for the experiment.
If the experiment is for a new, upgraded version then clone and then branch (hg branch) so you may keep all copies of the repositories updated without one experiment interfering with the other.
Linus Torvalds (who deals with tens-of-thousands of files and millions of lines of code in his projects) gave a talk at Google about why the tool can't be CVS, SVN, or any of the many free and commercial ones around; it is very much worth watching.
Best Answer
All code is temporary. When I'm making changes I will introduce placeholders occasionally - that icon that I drew waiting for the real one from the designer, the function I know will call the library that my colleague is writing and hasn't yet finished (or started), the extra logging that will be removed or otherwise made conditional, the bugs that I will get around to fixing once they've been noticed by the test team, etc
So check everything in. Use a feature branch for all your development, then you can merge the final version into trunk and no-one will need to know what hacks and bodges and fixes you made during your development cycle, they'll only need to see the final version. But if you've committed to your branch regularly, you'll be able to see the things that were worth keeping if a day went spectacularly wrong, or you continued coding after a lunchtime down the pub.
Version control is not a artifact repository or document storage system. Its about holding the history of changes. Stick everything you like in there becuase one day you might want to see what it was, and those are the days you realise what your SCM is truly about.
PS. Truly temporary files (eg .obj or build artifacts) have no place in your SCM. These are things that have no value to anyone. You can tell what they are - if you delete them you don't mind, or even notice they're gone.