Back in March, I wrote a post called How to check in changes on behalf of other users. Among other things, you’ll find the documentation comments for the Workspace.CheckIn() method, which you’ll notice is now on MSDN. While that and How to validate check-in policies, evaluate check-in notes, and check for conflicts are probably the best documentation on how to use CheckIn(), I didn’t mention that CheckIn(), which returns the changeset created by checking in, may return 0.
The version control server automatically undoes the pending changes in the case where you attempt to check in files that haven’t changed rather than create new versions of them. In the extreme case, CheckIn() will return 0 when all of the changes being checked in are edits without content changes or locks. Nothing bad happened, but the server did not create a changeset. If something bad happened, such as having one or more conflicts, CheckIn() will throw an exception.
The CommitCheckinEventArgs object, available by listening to the VersionControlServer object’s CommitCheckin event, contains the list of files that were actually checked in (Changes) and the files that were undone (UndoneChanges).