Just like you need to explicitely tell Subversion to commit changes you've made, you need to manually tell Subversion to update the working copy from time to time. When you update, the contents of your working copy are updated with all of the changes that have been committed to the repository since you last updated.
Subversion is pretty smart about updating and never just overwrites files that have local changes with copies from the repository.
The most important thing to take away from this section is: If you collaborate with others on one repository, remember to update your working copy regularly. Check the option “Show Updates from Repository” in the “View” menu to see which files have remote changes without having to constantly hit the update button.
Subversion can run into conflicts from time to time, most commonly when a co-worker has made changes to a file you were working on too. When a conflict happens, Subversion will first try to resolve it itself, which is easy when both changes were in very different parts of the file. If Subversion can’t figure out what to do itself, it will create several new temporary files next to the original conflicting file. These new files represent different possible versions (base revision, yours, your coworker's) of the file, allowing you to mix and match to resolve the conflict. The original file will contain both your and your co-workers changes. When you are satisfied with the your new version of the file, you can mark it as resolved. Subversion will then clean up the temporary files, making it ready to commit again.
One of the biggest advantages of using Subversion is that you can freely experiment with files, without actually messing anything up. The revert command lets you get rid of any local changes you have made. So if you try something and it doesn’t work out, undoing it is just a click away.
The revert command only affects the files or folders you tell it to, so you can revert changes to one file without losing any of your work on other files.