DSS comes builtin with Git-based version control. Each change that you make in the DSS UI (modify the settings of a dataset, edit a recipe, modify a dashboard, …) is automatically recorded in the version control system.
This gives you:
- Traceability into all actions performed in DSS
- The ability to understand the history of each object
- The ability to revert changes
You don’t need to configure anything to benefit from version control. However, by switching to explicit commit modes, you can get more control.
On the project homepage, click on “Changes”. The project’s history browser appears. You can view all commits made on the project. Scroll to the bottom to load more commits.
You can click on any commit to view the details and browse the changed files on this commit. By clicking on the “Compare” button, you can compare the state of the whole project between two revisions.
In addition, when you are in an object (dataset, recipe or web app), you can click on the History tab to view the history of only this specific object.
On the project’s change page, you can revert your project to a specific revision.
Reverting a project to an older revision will discard all work performed in all aspects of the project since that revision, by all users of a project.
Reverting only affects the configuration of the project (datasets, recipes, web apps, dashboards, ). It does not affect data. Thus, after revert, some data might be missing and might need to be rebuilt
Reverting does not affect Jupyter notebooks at that time. It is not possible to revert to older versions of Jupyter notebooks.
Click on the revision you want to revert to, and click on “Revert to this revision”.
From an object’s history tab, you can revert only this object (dataset, recipe, web app, …) to a specific revision. Other objects in the project are not affected.
Reverting a single object is a dangerous operation, since it might make the reverted object inconsistent with the rest of the project. Various issues may appear.
Reverting a single object may cause Git conflicts. In that case, DSS will not perform the revert. You will need to perform it manually using the Git command line.
We advise that you only use this option to revert to previous revisions only in presence of “simple” changes like changes in code rather than “structural” changes (changing inputs of a recipe, …)
On the project’s change page, you can revert a single previous commit. A “reverse” commit will be added to the history of the project.
Reverting a single revision is a dangerous operation, since it might make the reverted object inconsistent with the rest of the project. Various issues may appear.
Reverting a single revision may cause Git conflicts. In that case, DSS will not perform the revert. You will need to perform it manually using the Git command line.
We advise that you only use this option to cancel previous commits that only contain “simple” changes like changes in code rather than “structural” changes (changing inputs of a recipe, …)
Experimental feature: Support for pushing to Git remotes is experimental, with a best-effort support.
The version control in DSS is a regular Git repository (which can be managed with the
git command line tool).
As such, it is possible to connect it to Git remotes, for pushing the work done in DSS to any Git server or Git hosting service.
To manage remotes connected to the Git repository of a given project in DSS, go to the Changes page for this project and click on Manage remotes.
Managing remotes is not available if your DSS is configured for a single global Git repository.
The first time you push to a remote, you might encounter a “UnknownHostKey” error. You need to first login in shell to the DSS server and run a single “ssh” or remote git command to the origin you want to talk with in order to get (and verify) the SSH host key of this server. The key will be added to your “.ssh/known_hosts” file and DSS can then connect.
For example if you want to push to
firstname.lastname@example.org:myrepo and get a UnknownHostKey error, login to the server and run
ssh email@example.com. You will get a prompt to accept the host key. Accept it and you can then push to the origin.
Some servers use an algorithm for the host key that the Git component within DSS does not recognize (generally ECDSA). In these cases, you will still be getting the unknown host key error. To fix this:
- First, remove the known key for this host:
ssh-keygen -R myserver.com
- Reconnect with the
-oHostKeyAlgorithms=ssh-rsaargument to acquire the host key with an algorithm that DSS can read. For example, run
ssh -oHostKeyAlgorithms=ssh-rsa firstname.lastname@example.org.
When you install DSS, it is by default configured to have one Git repository per project, plus a global Git repository for “global” configuration elements (Administration settings, connections, users and groups, …)
DSS can also be configured to have a single Git repository for the whole configuration of all projects. Generally speaking, we don’t advise changing this setting. Using global repository makes it impossible to manage Git remotes.
To change this setting:
- Stop DSS
install.ini, and in the
mode = global
- Start DSS