I use Subversion for my projects here at home. At work, I use CVS for my main project (because it's hosted off-site), and svn for the internal projects (like Turnplay). There are a lot of things I like about CVS, but for smaller projects, SVN takes the cake, definitely. I don't care for its branch/tag methodologies, and it doesn't handle merges the way I would like, but shoot, when there are 2-3 active developers on the project, then I think those problems are minimal. I like the fact that svn's wrappers for adding, removing, moving, and copying make more sense than with CVS. I guess it's merely an opinion though.

Now, I just read a post about "Atomic Coding," and while the term is new, the concept is not. I'm a firm believer in committing often. Starting out a new project often means it's difficult to have everything hashed out and directories the way you'd like them. However, with recent commits, things can be backtracked fairly quickly. On the other hand, they talk a lot about committing on every small thing. I don't necessarily believe in that though. When I'm in bugfixing mode, I often won't fix two bugs in the same file (if they are, it's probably alpha code still, so it's not really bugfixing...) I'll skip around. I do, however, commit when it makes sense, and when I need to move on to something else.

While working on PeachPie, which I have recently ceased development on, I found that I had become quite anal about the repository management tasks. So I compiled a list for everyone that would be editing and committing code, with the commandments of the SVN repository.

1. Do Not Break the Trunk - This is the big one. Committing often is great. However, what happens when someone updates, and you've BROKEN the trunk. Now, not only are you not getting your functionality working, but you're preventing someone else from getting their functionality working. If you're not around, they either have to wait (which should result in a nasty email), or they have to clean up your work (which will most likely end in a merge conflict later on). If you're working on new functionality, and you've got it to a good stopping point in your progress, commit, take a break, read some blogs, and come back. However, if you're working on the main parts of the program, or even the build, make sure it still works before you commit. This means you might have to type `make` and make sure it builds and runs, but do it, or you could be lynched (and you would deserve it).
2. Don't Use Version Control As A Backup Tool - Use your backup tools for backup tools. I've been guilty of this once or twice, but just because the 5 o'clock whistle is blowing is not a good reason to commit your broken code. (See Rule #1) Wait until your bug is fixed, your feature is working, and your build is correct. Then, and only then, should you commit. If it takes you 30 seconds to do something, commit your 30 seconds of work. But if it's gonna be another hour, wait another hour on the commit.
3. Be Precise and EXHAUSTIVELY Verbose In Your Commit Logs - This means you. When I first became a software engineer, I was lazy (I still am, but I'm getting smarter with my laziness). I'd write things like "Fixed a bug with XYZ" There was no explanation as to where, or what. Sometimes, I'd commit files that I changed things in, but the commit log was for something entirely different. Think of your SVN comments as an extension of your code comments. Remember the 3 W's: What, Where, and Why. What did you fix? Why did you fix it? Where was the fix needed? It's a good idea to reference a Bug # or Ticket #, whatever. Just provide some linkage there. Maybe you'll have to write "Per product manager's email, adding widget to bucket" as part of your set of comments. Just don't think people don't look at those logs. Sometimes they can be more embarrassing than the comments you leave in the code from those 4 a.m. frustration fits... For more information, see Changelogs
4. Commit Often - Uh oh, I'm contradicting myself, right? Wrong. It doesn't take you forever to reach milestones in your code. If it does, you're in the wrong field, go get a degree in Social Work or something. I recently set up a backup service for our SVN repository. While watching some of the diffs go past, I saw that there were 6MBs of code in one diff. WTF? Who waited until they had 6MB of code to commit before they did it. Don't tell me that's 1 file. It's not, and you're a liar. It's TONS of files, from all over the place, that you've been working with and never committing. This is source code, not the latest Jay-Z album. Why is the 'MB' reference even needed here? Commit at milestones. That's means at least once a day. By doing this, you easily avoid breaking Rule #1, and making Rule #3 hard on yourself.
5. Do Not Commit Local Files - Gosh, I hate this one. I saved it for last, because it should be a no brainer. DO NOT commit the binary you just compiled. DO NOT commit your local 'settings.py' file. DO NOT commit your compiled Smarty templates. Are your getting my drift? `svn propset` is your friend. Learn to use svn:ignore if need be. Just don't clutter up the repository with code, binaries, and the like that don't belong there. I had someone commit a compiled binary one time, and I didn't realize it. This lead me to wonder why everytime I did an update, my compiled binary would be wrong. It was quite annoying until I figured out what was wrong. Then I said a curse word or five.

So there you have it. Five rules that will help you manage that unruly SVN repository. Maybe if you stick with these rules, you won't have to send your repository away to a youth ranch for troubled teens (inside joke, I couldn't help it).