Notes are a problem in all code and with all developers. Depending on ones view, there are too many or too few on any given day. In the end, we are all human and have our own preferences.
I am big on documenting code, but I believe it is more than just having more notes than you have lines of code. The idea is that your code should be clean (i.e. don't use 1 line when 3 makes your intent clearer) so that it tells most of the story. Then you add notes to those areas that just need a little help. Logging messages not only help the user know what is going on, but can also help document the code as well.
One solution that we used for Harmony was OpenSVN. Once the repository was set up, you could commit your changes and then, using OpenSVNX, could compare, using the GUI, changes others have made to the repository. You literally have side by side comparison and select those to accept in your version and those to reject.
I know you had some trouble setting up the repository so you went with CVS, but once we got it going, making changes was pretty easy. The only issue was when someone would change the nib files. There's no way to make a comparison. You basically have to coordinate who's doing what on the nib or you'll step on each other.
So I decided to create a AMP one-off which will have XM. Unfortunately I don't have the time to rewrite HXM, which is a java XM controller in objective-C to create a tight integration with AMP, so the interface is applescript to HXM. To maintain the look and feel of AMP i've decided to use radiosharks interface. So if you have radioshark and/or HXM, the radio button is enabled. To get to XM click on the radio button twice. For now there are two bands XM1 and XM2. What I'm working on now is to display the XM contents in the visible window (the dialog that comes up), since the radio display just shows the channel number. I would say I'm 80% complete.
I know this will be a bear to merge back into AMP and don't plan to do it. Whatever new features bobby adds I may incorporate them. Whoever created the project on sourceforge kudos to you. But adding to Tom's comments, it is hard working together on opensource projects. We all have lives, different coding speeds, distance...sounds like a marriage.
Well I did get everyone talking
The Version Comparison tool (can't think of it's name off the top of my head and am too lazy to look right now ) works with CVS too and is very nice (though outside of it being slow Java, I really like Eclipse's compare tool a bit better).
My big issue (and it appears to be the same for CVS and SVN) is that XCode doesn't have all the functionality built in to it. For example, if you add a new file/dir, you need to run the import and add commands at the command line vs having functionality in XCode itself. It is also painfully slow for commiting and retrieving from CVS (the command line and Eclipse's interface are orders of magnitude faster working with the same code from the same CVS servers). That there is no way to retrieve a Project (that you don't currently have) from CVS/SVN is annoying to (again you have to do it from the command line).
Given how much thought and effort Apple put into XCode, i'm more than a bit surprised that Source Management really feels like an after thought.
As far as coordination goes, that is indeed a big issue. Programming as part of a team is what I do for a living. You just have to setup best practices for the project (e.g. only commit working code, commit nightly, etc..). The comparison tools are there to allow you to merge differences if you are commiting from an older version because someone made another change in the meantime. It takes practice, but it does work.