On both clients, enter a different Description in project properties. This will simulate a conflict. Suppose one client enters My awesome game! and another client enters My SUPER awesome game!. If we then save and commit both, there's a conflict: what should the description be on the server?
The first client can commit just fine; as far as the server's concerned, nothing is amiss yet. However when the second client tries to commit, we get an error message: the server has noticed we're trying to make a conflicting change.
The second client's changes are not on the server yet - the server rejected the conflicting change. The work falls to the second client to sort it out. They now have to:
1. SVN Update, to download the other change that was made
2. Resolve the conflict
3. Commit the new resolved file
After the failed commit, TortoiseSVN offers you the option to update. Click Update so we can start sorting out the mess. You should see another warning that there is a conflict. Notice the project file now has a special warning icon to indicate it's in a conflicted state.
Try to commit again. The commit dialog lists the file as having conflicted status. Right-click on the conflicted file. Note you have options to resolve conflict using 'mine' (simply overwrite the file with what I've got), resolve the conflict using 'theirs' (overwrite my changes with what the other person made), or Edit conflicts (go through the file line-by-line and decide which lines to use where). The simplest way to resolve conflicts is just to pick someone's copy and use that (using 'mine' or 'theirs'). However somebody will lose their changes that way. Edit conflicts lets you choose exactly how to sort it out, but it can be a bit tricky.
Below you can see a screenshot of Edit conflicts where TortoiseSVN has highlighted the conflict on the description property, and gives you various options to deal with it line-by-line. The mark resolved button is circled in red, which you can use when done.
Once the conflict is resolved, you should then be able to commit successfully again.
Try the previous process again, but one client modifies the description, and the other client modifies the version. Here we come across one of source control's finest features: automatic merging.
Both changes have been made to the .caproj file, but each client changed different parts of the file. Then the second client will similarly get a failed commit, saying your copy is out of date and needs an update. Then when you update, it does something really smart: SVN sees that the other change does not overlap your change. So it automatically merges the change in to your local copy, then takes you straight back to commit. No conflict occurred.
In other words, suppose the first client changes the description and commits, and the second client changes the version and commits. When the second client commits, SVN automatically updates the second client's working copy with the new description, then commits a new project file with both the new description and the new version, avoiding having to do any painstaking conflict resolution.
Conflicts only occur when two clients try to change the same thing. Conflict resolution can be tricky and tedious, so you should co-ordinate carefully with your team members to avoid this, perhaps by assigning clearly defined roles. However it's possible for two people to work on the same file at the same time, providing their changes don't overlap, and SVN seamlessly merges together everyone's work. This is an incredible time-saver over trying to merge multiple changes by hand, and allows for much more flexibility in collaboration. For example, generally two people can change the properties of the same object, as long as they don't both change the same property at the same time. As long as the changes don't overlap, SVN can work out what you wanted overall. And even if two people do both change the same thing, TortoiseSVN provides good tools to clearly see who made which change, allowing you to raise the issue with the team and decide upon the final answer.