When I check-in code, I sometime write very long, detailed checkin notes, other times I write very short ones (or no note at all). The longer notes tend to include information about why the change was made (business reasons, customer interactions, etc). However, I'm not sure if check-in notes are the right place for such detail. Most check-in notes I've seen tend to be short and simply reference a bug.
What is an appropriate level of detail for check-in notes?
Whatever your manager or company documentation tells you ;)
That being said, shorter is better. It's not the correct tool for lengthy documentation - your bug/feature tracking software is built for this and in most cases, can integrate with your source control.
Just enough so, when following the log few weeks later to have an idea about what hapenned.
I use these logs to check what has been done in the last day (or days) in the project I'm leading.
Shorter messages doesn't necessary mean better. Nor longer messages. Just keep in mind the goal of those comments: to give an overview of the activity on versioning system.
In my version-control experience, I tend to curse the ones that left no note at all, or a note that takes 5 minutes to dig through.
If you use your version control system to browse the history of a file to find a specific change, it's best to include a short comment on the why, and the what. The how is to go in the source code documentation.
The right answer, I've found, is dependent on the needs of your organization. It sounds fuzzy, but the primary reason to provide detail for a code check-in is for context and understanding if that check-in needs to be reviewed or revisited. It might be incredibly verbose, or it may be remarkably simple.
In one company, our code check-ins would reference #+ticket-number. This mapped our SVN commits against a Trac ticket number, which held all of our details about a given issue or feature we were implementing. We referenced everything through Trac, so keeping our details in that form worked best for us.
For you, it depends on how you and your team work. I would base what info you keep in your check-ins on the need for the data, how often its referenced, and what happens if you lose context (i.e., have no idea why a change was implemented.)
Another consideration may be accessing those notes outside your code repository, which may not be the most effective mechanism for storing that information. Nonetheless, I find it's personal preference.
Whenever I write a comment or a commit log message I ask myself "what will the next guy need to know? what are they likely to ask me about?"
Answering a question seems to be the easy way to keep comments brief and useful. It also avoids anti-documentation (rephrasing code, often in unintentionally ironic ways) or re-phrasing the metadata the vcs will be tracking anyway (added foo.java, tuesday change, new tag "bar-1-1-4")