Setup your repository with something like:
/tags
/trunk
/branch
- Put the latest version of your code in trunk
- Tag releases or builds into a version-named folder in tags (consider these readonly)
- Branch releases into a version-named folder in branch (these are readwrite bugfix branches)
Tags/branches do not use up extra space until new revisions are committed into them. To that end, our build process automatically creates a tag for each build (not necessary, but simply an example of their usage)
The general flow is:
Checkout a repository (usually a specific branch or trunk) locally- Make changes
Update to merge changes (and resolve conflicts)Commit the changes back into the repository
Other things to consider:
- Renaming files/folders. Use SVN -> Rename whenever possible to ensure you keep your history.
- Complex changes. If you are going to rename a folder and move files within it, try to commit one change at a time. Multiple deletes/moves/renames/adds within the same tree can sometimes cause SVN to get confused. You'll learn which specific scenarios to be careful of yourself over time.
The only other feature of note is adding a property (files Properties -> Subversion -> Properties) "needs-lock" with the value of "*". This will restrict the file to be modified by one user at a time (until they release the lock). Useful for file databases like SQLite, since they are binary and cannot be merged.
You can learn the rest yourself by simply playing around with it.