The number of changes in a changeset is stored as the CLR's int
type. So there's definitely an upper limit of int.MaxValue
or 2,147,483,647
. I don't think there are any checks to limit the number of changes in any other way (though I may be mistaken.) Realistically, you probably have disk space contention to deal with on the server long before you reach that value.
One of the specific design goals of Team Foundation Server was to deal with large changesets - particularly merging large feature branches with a lot of churn - which can produce a changeset with a large number of merge or merge/edit changes.
In short, no. And even if there was, hundreds is several orders of magnitude off. There should be no reason to split them into multiple changesets - you only do yourself a disservice by doing that. You're hurting traceability by doing this and basically devolving into a non-atomic system (yay, CVS!) and makes the state of your repository unreliable. It negatively impacts continuous integration, linking to work items and builds and overall traceability. Imagine checking in half your merges to a branch... then the other half. That sounds like a nightmare.