Component sizing guidelines

Edit online

When you plan your component structure, consider breaking up components by following architectural patterns and avoid circular dependencies. Components should contain files and folders that belong together. If a new project is split into distinct teams that work on different parts of code, you can start by creating one (or a few) components for each team.

While there is no hard limit to the number of components in a stream, the recommended maximum number of components is 2500, with up to 100,000 files and folders per component. If you load and track multiple repository workspaces in the Pending Changes view, then the total number of components in the tracked repository workspaces must not exceed 2500.

The following table compares the differences between creating a few large components (coarse-grained) versus many small components (fine-grained).

Table 1.
Creating a few large components

Major points: A change set is associated with a particular component. You can move files from one component to another, but you cannot apply change sets that are created in one component to another component.

If you have multiple streams and you are working in parallel on a set of components, avoid moving files from one of those components to another, unless you must perform a one-time move where all streams accept the move at once (so no team is creating change-sets for a file in the original component while other teams are creating change-sets for that file in a different component).

To avoid the move issue, add all the related projects (between which you might want to move files) together in one component.

Minor points: Occasionally, you need to change the component list of a workspace or stream. The more components there are, the more cumbersome it is to change longer lists.
Creating many small components

Major point: You can easily adjust the configuration of a component independent of the configuration of the other components in your workspace. In particular, the scope of a baseline is a single component, so you can identify interesting component configurations with baselines, and at any time adjust the configuration of that component to be an arbitrary baseline that you select.

Minor point: You can selectively load components, so smaller components make it easier to load just the specific files you need. However, if there are a set of projects you always load together, it is better to have them all in one component, to avoid forgetting to load projects that you need. In general, group projects together into a single component if they usually need to be loaded together.

If the project source code may be required to have different restrictions over the life of the project, having more components adds greater flexibility in applying that restriction (by changing the ownership and visibility of individual components).