If you ever wondered how to set the dependencies between different Plastic SCM repositories or you have been struggling to share common repositories using Xlinks , you will probably find this post helpful.
Let´s review a scenario where a video game company has a shared engine that is being used at the same time by two different game studios (in different locations).
Each game studio will have an "engine" repository and a "game" repository.
The goal is to share the engine code between the two studios and, at the same time, the engine developers internally continue evolving it in New York.
How does a workspace look like?
This is the workspace of a developer who works in the Game A at the Vancouver studio. There is a folder containing the game code and also an Xlink pointing to the local "engine" repository.
But let´s now review in deep how the engine repository should be configured to succeed in this scenario.
Engine repository configuration:
As the engine might be different in each game studio, the “engine” repository has internal branches to handle the specializations. We create a new branch per game. This set up allows each game studio to use the engine code and modify it independently.
In the Vancouver studio they create a new branch for this purpose.
The good point of using specific branches per game is that interesting fixes or new features can be merged or cherrypicked between branches and then easily replicated to the remote sites.
In our example, the studio located in Vancouver develops a fix in the engine that is considered indispensable for his colleagues in London (and other future studios). In order to share the fix, they perform a merge from his specific branch to the "main" branch of the "engine" repository.
Finally, they just push the new created changesets to the engine central repository in New York. Now the new engine version (including the fix) is available for all the studios. So the other studio in London just need to pull the new stable version of the engine and rebase it to their working branch (remember that every game studio has a specific branch in the "engine" repository).
Games repositories configuration:
The game studio locations also need to configure their local setups. There will be a “gameX” repository containing the local game source code and a local “engine” repository. This repository will be a replica of the New York´s engine.
The way the Plastic handles repository links are creating Xlinks. So we create an Xlink in each "game" repository pointing to the "engine" repository.
Notice that the Xlinks are pointing to the specifically created branches per each game.
When the Xlinks are created, we also have to properly adjust the branch auto expansion rules. This way, we can keep the independence between the two games although they are actually using the same Xlinked "engine" repository.
Note: We select both options:
Share the engine changes between games:
This game independence doesn´t limit the propagation of the changes performed in one game to the other. It can be performed in two easy steps:
Finally, It´s interesting to realize that using this workflow, we can avoid replicating the entire "engine" repository per game studio location. We can just sync the desired branches on demand avoding unnecessary disk and network usage.
It means that the Vancouver studio doesn´t need to sync the "/main/GameB" branch because they are only working in the GameA.