Lewin, I fear that you completely misunderstand what the icons represent. (NB: in the discussion below, I use the Subversion command- line commands, which are generally the same as the TortoiseSVN context- menu commands.) Reading the Subversion documents would be a good start for you, as svn doesn't work like VSS.
When you see a green checkmark, it means that your local working copy is unchanged from the revision you checked out of the repository. Another user may have checked out, modified and committed changes to the repo AFTER you checked out.
When you see a red exclamation point, it means that something in your working copy has changed from the revision you checked out of the repository. It shows that YOU changed something. It does NOT mean that the repository has changed.
The icons are simply a visual indication of the "svn status" command. If you were to go to the command line and run "svn status" in the working copy, you'd see an "M" for all of the files that you modified. This is all local working copy stuff and has nothing to do with what's in the repository.
When you do an "svn commit," your changes are added to the repository as a new revision and the head is bumped.
If you were to read the Subversion book, or perhaps the TortoiseSVN help doc (which is pretty good), there's a discussion about general Subversion usage. They point out that "typical" usage is as follows. You check out a working copy, make your changes, and commit back to the repo. Many developers keep "long-term" working copies, meaning that you check out at the start of a project, and keep that same working copy for the duration of the project. In this case, at the start of your work day, you do an "svn update" to grab any changes that your team may have made while you were asleep. "svn update" silently merges their changes with yours.
Now if you go to commit changes and your working copy of "out of date," meaning that someone else committed to the same trunk/branch, you'll get the conflict notification, and you have to merge your changes with what's in the repo. Tortoise Merge actually does a good job with this, but you of course have to inspect each difference, and make sure your changes and your colleague's don't conflict, and then you commit the merged file back to the repo. Obviously, if you're used to VSS where only one developer is allowed to modify a file at a time, this can be scary and non-intuitive, but in practice, it's relatively straightforward. (Merging branches back into the trunk is trickier and it's worth creating a test repo/project to experiment and learn how this works.)
Also, the Subversion book and docs also say that you should communicate with your colleagues so that your changes don't bollix theirs.
You can use Subversion for binary files, which are usually impossible to diff and merge. You should implement locks for these files, which basically makes Subversion work like VSS in that only one user can grab a lock and modify a file.
Good luck. I think part of your problem is you're used to VSS and Subversion is different.
-a