The Snapshot Plug-in and Git

In order to understand the Snapshot plug-in, you need to understand a little bit about how git works.

Most version control systems prior to git were centralized systems. All users of the system would "check out" a copy of the files they wished to work on from a central repository, and then periodically "check in" the changes they had made. All recording of versions, resolution of conflicts, creation/merging of branches and so on was performed in this central system.

Git is different in that it supports synchronization between repositories. This means you can have many different repositories (or repos) containing different versions of the same files, and use git functionality to keep the repos synchronized in whatever way best suits your requirements. It is common practice for every developer working on a project to maintain his own local repo into which she can check in changes, resolve conflicts and create/merge branches. There doesn't have to be any central repo, although in most situations it makes sense to have one. When a user wishes to save a set of changes, she does so by committing the changes to her own local repo, and can add a message describing the change. Changes committed to a local repo can be later copied to any other repo (usually some kind of central repo) by synchronizing the repos.

The Snapshot plug-in is designed to support this development model. For each blueprint, it knows about two git repositories: a local repository on the Content Engine server and a remote repository which holds the central version of the blueprint, accessible to all users. In a typical Escenic-based operation there are three or more parallel installations to consider: production, test and development. In the case of development, each developer usually has a personal server installed as a virtual machine image on his PC. Each Content Engine instance has its own Snapshot plug-in with one or more local repositories containing blueprints. All of the Snapshot plug-ins, however, are configured to communicate with the same remote git server. In this way, all the installations have access to the same, shared remote repositories: