Is there a limit on the number of files in a chang

Question

I've done some searching but have not been able to find out if there are any limits in TFS to the number of files in a single changeset.

This came up with IntelliJ IDEA where we found that it was splitting up changesets with >200 files. I want to argue that there shouldn't be any limit at all, or at least the limit should be the same as TFS' own limit, if there is one. See the defect I reported on this issue at http://youtrack.jetbrains.net/issue/IDEA-54846.

Answer 1

Based on my observations for our TFS site, the number of files in a TFS changeset is at least 11670.

USE Tfs_Warehouse;
GO

SELECT
    FCC.ChangesetSK
,   COUNT(1) AS row_count
FROM
    dbo.FactCodeChurn FCC
    INNER JOIN
        dbo.DimChangeset DCS
        ON DCS.ChangesetSK = FCC.ChangesetSK
    INNER JOIN
        dbo.DimFile DF
        ON DF.FileSK = FCC.FilenameSK
GROUP BY
    FCC.ChangesetSK
HAVING
    COUNT(1) > 200
ORDER BY
    2 DESC;

Partial results

ChangesetSK row_count
53172   11670
4436    7940
4442    7808
43808   6262
21016   6047
53173   5835

Answer 2

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.