BASE is the revision of your working copy as it exists in the repository. In other words, your revision without the changes you've made. So if you svn update a file or folder to HEAD, then BASE and HEAD are equal.
When there is a conflict, BASE becomes the revision before the commit that conflicted with your working copy.
Run svn info on an item to see it's BASE revision.
HEAD is the latest revision in the repository. BASE is the last revision you have obtained from the repository. They are the same after a successful commit or update.
When you make changes, your files differ from the BASE copies. When you revert, they go back to matching the BASE revision. When you get a conflict, you do not update the repository. Rather, your files are considered to still be "being edited" as if you were making changes. After you resolve conflicts, you have in essence decided what the final files will look like and you then commit them as you would have normally. So, conflicts are like a case of special editing.
Theory: After a successfull recursive update or switch the base version of all your files becomes head. After a commit or partial update some files might be at the HEAD revision, but only after an update that didn't skip files you can be sure that all files are at the same version. (Reasons for skipping are unversioned obstructions or conflicts).
But, why would you need to know this. Subversion should know this internally, but this knowledge shouldn't really matter to the user in most cases. (Subversion automatically warns you when files are out of date).
As far as I can tell, the only time you really need to make sure that you are at a stable version is, when you are creating a branch from a working copy.
It matters when you are viewing logs, because svn log without url shows your BASE log, but with url your HEAD log, that's why i always use "svn log -rHEAD:1" to see all the changes.