To me, a project log is to documentation as Twitter is to blogging--it requires little effort but over time provides useful pointers to where you were at the time.
Originally I used a "one way personal wiki" to keep track, like this: http://code.rancidbacon.com/ProjectLogArduinoUSB
But when I lost the server it was on I decided to re-implement it on Google App Engine and make it available to other people, thus was born Labradoc, here's an example project log: http://www.labradoc.com/i/follower/p/project-sms-text-scroll...
It's kinda a "commit log for your day".
Yeah, it's really helped with those "now, what was that command line I used?" and "how did I solve that problem last time?" type questions too.
And not just for yourself. It also helps other people pick up "incomplete" projects you might have lying around that you cough haven't got around to documenting yet.
I started out with just writing single line entries but because they proved so useful it encouraged me to spend a little more time writing longer entries. (Although I often end up with a whole bunch of browser tabs open as a result. :) )
I don't use it anymore, but this was how I got started on this approach: http://akkartik.name/codelog.html
Here's a kinda-random sample from my current obsession: http://github.com/akkartik/wart/compare/587e30dc51...8da3d3c...
The numbered filenames are one example. Each file is intended to be self-contained, and later files build on earlier ones. No need to hack on makefiles to add a new file. Just create it, number it right, and it'll get compiled, with access to everything in earlier files.
Since this is a lisp interpreter the ethos translates to lisp functions as well. I can improve performance by deleting a lisp function, reimplementing it in a new .cc file, and restarting the interpreter. The interpreter will transparently run make, which will transparently compile the new file. And tests on the lisp function will continue to pass if I did the translation right.
There's a README (http://github.com/akkartik/wart#readme) that tries to convey my goals, but I haven't had too many people read it yet. I'd love to hear what isn't clear. You aren't supposed to know lisp to understand it.