Working together and working apart: centralized and distributed development
We mentioned earlier that version control systems can implement either a centralized model or a distributed model:
- Centralized version control systems use a single repository from which users check out one or more files to work on in their local directories.
- Distributed version control systems allow users to host repositories locally, check out entire repositories with history—or, in the case of Helix Server, a subset of repositories—work independently of one another, and combine their work through merging when necessary.
Helix Server supports either model, as well as a hybrid of the two.
In the centralized model, clients work with a depot on a shared server. A mapping of files from the depot to their workspace determines which files they are able to work within their workspace:
Users check files out of the same depot, work on them, and check in their changed files. If multiple users work on the same file, they use merging and conflict resolution to make sure the resulting version is satisfactory to all authors. Although users can disconnect from the shared server and continue to work on the files in their workspace, some manual work is required to sync back to the server and to check in files when the user reconnects. For information on working with Helix Server using this model, see the Helix Core Command-Line (P4) Guide.
In the distributed model, users work with a depot on personal servers that are then connected to a shared server. The depot on their personal server might contain a subset or the entire set of files on the shared server. Each user can work disconnected from the shared server but still be able to access all the files in their workspace and place these under version control using their personal server. Each user can access the entire history of a file locally, rewrite and revise history, and manage the files and streams on their local machine without interacting with the shared server:
When users decide to share their code or digital assets with other users, they connect to and then push their content to the shared server. This allows other users to fetch that content from the shared server and work with it on their own personal server. Users might need to merge content before pushing if their changes conflict with changes made by others.
In addition to supporting these two models, Helix Server also allows for a hybrid architecture in which some users connect directly to the shared server while others connect to personal servers that are connected to the shared server.
For more information about distributed development and file management, see Using Helix Core Server for Distributed Versioning.