What do you think is the best practice for checking in code from multiple files that implement multiple changes, but are ready to go in at one time?
Do you check them all in at once, keeping the checking reasonably atomic, and put the changes in one long comment?
Do you check in the files in groups so the right comment is associated with the right file?
Do you have tools which let you check in at once with different comments on different files?
I try to keep each check-in related to a specific ticket number, project, etc.
Keeping checkins as small as possible is good practice for a number of reasons, especially if you want to roll back anything. For this reason, try and check in code in the smallest "meaningful" increments possible (as long as everything still compiles after each checkin).
Check all at once. If you check in groups you make break the build.
But it is better to check in as you get the change done.
I use Git, which allows you to easily resolve the tangled working copy problem. I can work away without worrying about which changes are related to what, then after I've done a few things step back and commit each logical change individually, with its own commit message.
This method is great for keeping small, logical changes together. If I look back at the history of a file with git annotate, I can easily see why each change was made without having one commit covering a whole bunch of unrelated changes. Furthermore, as somebody else mentioned, having smaller commits makes it easier to roll back a previous modification if you change your mind later.
So long as their aren't dependencies among multiple changes, keep your check in's small. Check in the smallest collection of changes that won't break the build or introduce other problems.
For bugs or small change request, usually one check in per bug (or change) tends to work best. This allows you to easily identify which file (or files) were updated to address a particular issue. this is not only helpful in rolling back changes but also in determinie what changes were made to fix an issue should a similar problem arise in the future.
For major changes, if they can be broken down into smaller units of work to be checked in, do so. A - if you do need to roll back something because of a minor mistake, having to rollback all of the changes is just plain depressing. B - hard drives crash - if you are working on something for an extended period of time, the more changes you implement and the longer you work without checking in, the greater risk you are putting your work and your organization in.