If there's more than one person working on a project, chances are (although slim) that at some point two developers work on the same piece of code and check it in. To clarify, let me give you an example.
The repository is currently at revision 5 and contains a file named 'README'. Revision 5 of that file contains a single line: 'This is a README file'.
Now, both you and your colleague check out r5 and edit README. Your colleague changes the line to 'This is a documentation file' and commits it back to the repository, which is bumped to revision 6.
You're an island, and have no clue about the new revision being created. You just happily write away and change the README file to: 'This is fun stuff!'.
When you commit your changes, you'll get an error message:
This is good. Subversion has detected that the file you want to commit has changed since you last updated it. Update the file to get it up-to-date again.
The 'C' indicates there is a conflict with the README file, and Subversion does not know how to solve this. You are called in to help.
If you now take a look at README, you'll notice that there are several markers that indicate what parts of the code are conflicting. You can easily see what you changed, and what has changed in the repository:
With option 1, you're done. With options 2 and 3 there is some more work to do, because you didn't commit your changes yet. Because we're dealing with conflicts here, I recommend you don't just commit to your repository, but follow a slightly different route.
First, update your working copy (again) to make sure you have all the latest, and are not trying to check in any more conflicting code. If any conflicts pop-up, fix these first.
Now, run your tests to make sure everything is working as it should.
When all is clear, commit your changes to your repository as you normally would.