Version Control Systems are particularly usefull when several developers have to share and historize their work.
Choosing a Version Control System
Stambia Designer is built on Eclipse foundations.
Thus, it is possible to use most Eclipse-compatible Version control plugins.
The first thing to do is to check if your company already uses a VCS. If yes, it is generally a good idea to choose this one (people already know how it works !) - if it is distributed as an Eclipse plugin.
The most known are CVS, SVN and Git ; note that this list is not limitative nor a particular recommendation. You will have to select the system which will best suit your requirements and your approach.
You will also have to learn how to configure, administrate and use your version control system - it is a third party software for which documentation and support are supplied by their editors, not by Stambia.
That being said, we are pleased to give some advice below in order to make a good use of your version control system.
What should I synchronize ?
The "global" project
We recommend to synchronize the "global" project. The idea is that all developers share the same template versions.
They will also share the same Configuration list and Runtime list. If you don't want to synchronize these, simply ignore "conf.cfc" and "conf.efc" files (see your VCS plugin's documentation on how to ignore/exclude files).
Note: when creating a new workspace, a "global" project is created. You can delete it from your new workspace, and import the "global" from your VCS repository.
The metadata
Of course they can (and should ?) be synchronized. They are central elements of a stambia project.
All developers working on a common project should work with the same metadata. They should fetch them frequently, to get the latest version.
Some of our customers have set their organization so that only a few people are authorized to modify and commit Metadata.
The mappings and processes
Needless to say! But read carefull the next one:
The "indy.diagram" folders
The contents of these folders are generated when saving mappings and processes. They contain your diagram layout and also your Notes.
This is why we recommend to synchronize them, and commit them along with your mappings and processes.
Not the "indy.build" folders
We recommend not to synchronize these. They contain temporary internal files, not worth sharing, and fetching them from a repository may lead to errors.
By default some VCS ignore them. Please make sure they are not synchronized.
Not the ".settings" folders
Each project may contain a ".settings" folder which reflect your preferences for this project. We recommend not to synchronize it.
Other useful advice
Avoid conflicts: get organized and communicate
When two people try to commit the same file, there is a conflict: which version is the right one ?
Some VCS offer "merge" features. These can be handy for programming languages (Java, C++, etc.). But in the case of Stambia, your source files are XML Files with quite complex/generated content. You may not want to deal with merge analysis of this XML content! We recommend not to use Merge features on Stambia files.
So the best solution is to avoid working on the same mapping / process / metadata as someone else.
Also make sure that you fetch the latest version before starting to work on it, and make sure that you commit frequently.
If there is a conflict, simply decide which one of the two files should be kept. And the other developer will have to report his modifications.
Create "tags"
Most VCS offer the "tag" feature. It lets you take a picture of your developments, so that you can refer to it later (revert, compare...).
Fetch and commit frequently
This will ensure that you work with the latest versions of your Stambia files, and that your colleagues will not override your work.
Use the same version of Stambia Designer
Stambia Designer stores your developments into XML files which can evolve as the Designer evolves. It is necessary that all developers who share developments use the same Designer version.
Especially, do not edit developments with an older version than your colleagues'.