You might want to take a look at the following pages before exploring revisions:
Simexpal supports two kinds of revisions: “normal” (static) revisions and develop (dynamic) revisions. If you have a finished project and only want to run experiments, normal revisions will suffice. If your project is not finished yet and needs refinement depending on factors like runtime or experiment outputs, you can use develop revisions.
Revisions contain builds and their desired versions. The versions can be specified in the following ways:
- SHA-1 hash of a tagged commit (recommended)
- SHA-1 hash of a top commit
- branch name (resolves to top commit of the branch)
For reproducibility reasons we recommend specifying the SHA-1 hash of a tagged commit.
To specify a normal revisions, we use the
revisions key and set the value to a list of dictionaries containing
name: name of the revision
build_version: dictionary of (build, SHA-1 hash/branch)-pairs
1 2 3 4 5 6 7
revisions: - name: main build_version: 'simexpal': 'd8d421e3c2eaa32311a6c678b15e9e22ea0d8eac' # SHA-1 hash of a tagged commit - name: secondary build_version: 'simexpal': 'master'
In the example above we created the revisions
secondary, which both contain the build
main revision contains a tagged version of simexpal, whereas the
secondary revision contains the latest
commit of the
If our revision had more than one build, we would simply add new lines of
'<build_name>': '<SHA-1 hash>' below the
'simexpal': '...' line.
Specifying develop revisions works similarly to specifying normal revisions. The differences are:
- we add another key
developand set its value to
- we leave the values of the
build_versiondict as empty string
Values specified in the
build_version dict will be ignored for develop revisions and simexpal will clone the
latest project files.
1 2 3 4 5
revisions: - name: main develop: true build_version: 'simexpal': ''
It is possible to have normal and develop revisions at the same time.