I\'m working on a project:
Metadata. You can tag and comment on checkins. Even though I work in a team environment I often use this to maintain my train of thought and/or keep track of items I have completed.
Revision history. Knowing which changes happened when and how it affected your project. It's also just good practice to be in the habit. If you ever expand the project and need more people to help, you'll already have a repository for other people to work with.
Once you start using version control (for a small project, may I recommend the easy to setup Bazaar?), your question will answer itself almost instantly, and with a clarity no discussion board could ever provide :)
The feeling, "Oops. Guess I should have spent time on that" in a job interview isn't fun, especially on something so helpful/essential. Prospective employers like to see flexibility and responsibility, even if your CV of code is great. :)
I've found that using version control (git is my preference) keeps me disciplined into rolling out batches of progress in my code, and I suspect it leads to other best practices as well.
I'm also a solo developer and I've never shared a repo.
To play devil's advocate, I am thinking Distributed Revision Control is more useful than just a simple version control system that is centralized.
For an individual developer, distributed tools are almost always much faster than centralized tools. This is for a simple reason: a centralized tool needs to talk over the network for many common operations, because most metadata is stored in a single copy on the central server. A distributed tool stores all of its metadata locally. All else being equal, talking over the network adds overhead to a centralized tool. Don’t underestimate the value of a snappy, responsive tool: you’re going to spend a lot of time interacting with your revision control software.
Distributed tools are indifferent to the vagaries of your server infrastructure, again because they replicate metadata to so many locations. If you use a centralized system and your server catches fire, you’d better hope that your backup media are reliable, and that your last backup was recent and actually worked. With a distributed tool, you have many backups available on every contributor’s computer.
The reliability of your network will affect distributed tools far less than it will centralized tools. You can’t even use a centralized tool without a network connection, except for a few highly constrained commands. With a distributed tool, if your network connection goes down while you’re working, you may not even notice.
Also check out Kiln and Fogbugz (which work in combination with Mercurial) They offer free accounts to students or teams of one or two people. http://www.fogcreek.com/
When you look at that, You might wonder why of all things I would recommend a distributed version control system to a single dev...
Well, overall I think its extemely useful, and Kiln and Fogbugz is super easy/fast to set up.
The key thing is, that merging of branches work way better in distributed version control systems like mercurial or github. So if you got a good part of your current project coded, and you have a really wild idea, you can branch it, and when the idea actually works, merging it back works really well. And because the merging works, until you find your wild idea works, you can still add other features and fixes to the trunk in the meantime.
Kiln's commenting / review functions that are syncronized with your versions make sense for a single person also, I think. I know I have to remind myself of needed improvements to some part, or to review something, or I'll forget.
This package is really well integrated and worth trying, they have good and short blurbs on the concepts on their site.
If you think its overkill, maybe so, but I think the extra horsepower in this setup will not get in your way.