For our WTF Project we have been using svn as our revisioning control system. It is terminal based and, for our purposes, simple and powerful enough. Using svn allows us to work on a local directory and upload it to a repository when we commit it. Uploading it to a repository means that any team members assigned to the repository can get the latest version to their local directory by updating. This means that any team member can work on the files from anywhere, at anytime and commit the changes to the repository so that other team members can update their local directory from anywhere and anytime. Of course this committing and updating requires good communication across the team otherwise there will be conflicts when committing and updating.
When all team members are able to communicate effectively, running into conflicts will almost never occur. So most of the time, using svn to commit and update is very easy. But when there are conflicts, perhaps using a source control with a gui would be easier. In svn when you run into conflicts, it can be quite hard to figure it out. Sometimes it is just a simple merge of code and reviewing it and then resolving the conflict. And sometimes it has to do with hidden svn files and directory structures that can cause a lot of confusion and trouble. But when it comes to a situation like that and I can't seem to solve it, I just backup the files I've changed to a different directory and delete the whole local directory and check it out. After the checkout, I just copy the code from the backups to the local files and commit.
So for anyone planning to use svn, the main commands you need to know are: checkout, update and commit. Everything else can be Google'd when it arises. Use checkout for a fresh local directory copy of the repository. Use update if you already have a local directory to get the latest version from the repository if any, I always use this before I start coding away. And finally use commit when you've made changes to files, so that it uploads the changes to the repository. Also don't forget to use the -m for committing files, it allows the person committing the changes to comment what he/she is updating/changing. This is very useful when the group is planning to go back to a certain revision number.