You add the project file to the repository once.
Then any number of people can check out a copy of it.
Most of them will not need to modify that copy, so they obviously don't commit the file over and over again.
However, if for example someone adds a file to the project (or changes compiler options, or whatever), then he would commit the project file afterwards. That will upload the changes made to the repository. The other users will see those changes when they next update.
This was the simple case (one person making modifications, several reading).
Now, what happens if two developers make changes to the project file at the same time and commit? Very likely, the changes will not be in exactly the same line, so Subversion will merge those changes automatically. To ensure that this works reliably, Subversion checks whether your revision is the same as the one in the repository and possibly requires you to update before letting you commit. During that update, the changes made by other people are merged to your working copy, which you can then commit.
Someone who updates after this will see the changes made by both developers.
Finally, what happens if two people happen to change the same line in the same file at the same time?
In this case, the changes cannot be merged automatically (since Subversion does not know what to do). If this ever happens, you will get a message about a "conflict" when you update. You can then resolve that conflict using a tool like for example TortoiseMerge, it is usually quite painless. After that, you commit, and all is good.
The only thing that is really ever a problem is binary data. For these, it is best to use locks and to communicate before changing them.