I've never worked with a VCS, so please correct me if I make any fundamental mistakes.
For a project of mine, I've chosen to use Subversion, and I've been reading the documentation. If I understand correctly, the revision number is incremented for every check-in. However, this brings up a question. Is it possible to checkin more than one file at a time (so the increment is only one)? Also, what if, say, a checkin doesn't compile... will the revision number be incremented?
Is it possible to checkin more than one file at a time (so the increment is only one)?
Yes, this is possible. See Does Subversion have Changesets? from the official FAQ.
Also, what if, say, a checkin doesn't compile... will the revision number be incremented?
You would usually test first whether the current state of things compiles in your testing environment, and check in if it does.
You could automate this using a pre-commit hook that runs your tests, and on that condition continues with the check-in.
The revision number is atomic, which means it applies to the whole raft of changes for one single commit, incrementing the revision number by one at a time.
The revision number would increment regardless whether it compiles or not, as Subversion does not have any knowledge or association with your specific technology stack in order to determine successful build or not.
You typically wouldn't commit if it doesn't compile locally. If you do, you 'break the build', and should put money into the team 'kitty'. ;-)
Yes, you can check in multiple files at once, and this will only increment the revision by 1.
In your second question, I don't think you mean "compile", since revision control systems don't care about whether or not the code they control is compileable. I think you mean "commit". In that case, the answer is that subversion commits are atomic. They either completely work or completely fail. It is impossible to attempt a multi-file commit and have some files succeed but not others. A failed commit does not increment the revision number.
Subversion commits are transactional. Either the entire commit succeeds, or the entire commit fails. If the commit succeeds, then the revision number is incremented. So thoe whole of your commit, no matter how many files it contains, will cause the revision number to increment by 1.
Subversion has no way of knowing if your code compiles. So, if you commit broken code, then you commit broken code, but the revision number still increments. You can't roll-back a commit (at least, not easily and not without considerable inconvenience).
If you need a build server, I can recommend JetBrains TeamCity. TeamCity comes with a VisualStudio plugin that lets you do a 'pre tested commit'. That is, you submit your code to the TeamCity build server, which builds the code. If (and only if) the build succeeds, then TeamCity commits your changes to Subversion for you. If the build fails, then TeamCity notifies you and does not commit the code. It works nicely and helps to prevent embarassing broken builds :)
Some version control systems use a revision number for each file. Subversion uses a single revision number for the entire repository. When you do a commit, you can have Subversion commit the changes you made to a single file, multiple files, or even every file that has been changed since your last checkout (see the documentation for svn add, svn revert, and svn commit). Subversion treats the commit as an atomic transaction; that is, no matter how many or how few files you commit, all of them are committed in a single operation that either completely succeeds or completely fails (in which case the repository is not modified). Every time you issue a commit command, the revision number for the entire repository increments.
Subversion doesn't know whether or not your code compiles, so there isn't anything preventing you from checking in bad code. You can use Subversion to store any type of file, not just source code, so Subversion doesn't try to verify the functionality of anything you check in (since attempting to "build" a repository full of text files wouldn't make sense and since there is no reliable way for the server to guess your build system or how to compile your code). That being said, it is possible to tell the Subversion server to run a script whenever a commit is attempted but before the transaction is processed (called a pre-commit hook). Some people use this feature with a script that attempts to build the source code (including the incoming changes). If the script is unable to build the source, it returns an error and Subversion refuses the transaction (on your end, you would see the commit operation fail). Auto-building source code is not something that is built into Subversion by default, but it is not too difficult to add if it is something you are interested in.
For more information, I highly recommend reading through the (free) official Subversion book "Version Control with Subversion". It's an easy read, contains almost everything you would ever want to know about Subversion, and has lots of examples.