Continuous Integration exposes the Atomic Change-Set illusion

Many source control systems offer the feature of "atomic check-in". That is, when the developer checks in their changes, they are grouped together in such a way that they are all successful or unsuccessful together. Everyone agrees that say this is a core requirement of a good source control system.

The primary purpose of atomic check-in is to force the developer to resolve conflicts with other code before committing their changes. From that perspective, atomic check-in works just fine.

But there is another requirement that atomic check-in is used for. That is the ability to group arbitrary sets of changes together (an atomic change-set). From this perspective, the purpose of atomic check-in is to support the ability to easily merge a change from one code-branch into another.

If you have multiple check-ins for one "real" functionality change, then atomic check-ins start losing their helpfulness. This was not that apparent when developers only checked in code once a week. But those days are gone. Today, developers doing continuous integration check-in several times every day.

And merging those changes has become hard (again).

Source control systems are missing an additional level of change management - the ability to group sets of changes together into a single meaningful change-set.

Do any source control systems do this? I think AccuRev might, although I have not used it so I don't know for sure. Certainly Perforce, CVS and SubVersion do not. (Perforce jobs do not count).