On the repository management page, an overview of the existing repositories for which working copies have been checked out is visible. Each bubble represents a repository and each grey box represents a working copy from this repository. The screenshot below shows an example where several working copies from a number of different repositories have already been checked out.
- SVN or Git account and repository url to check out are needed to complete these steps
- SVN urls are often similar to https://svn.server-name.com/my-repository/trunk/my-subfolder
- Git urls are often similar to https://github.com/my-organization/my-repo or https://gitlab.com/my-organization/my-subgroup/my-repo.git.
For more information about repositories, working copies, SVN and Git, see Use version control.
Checkout/Clone Content from SVN/Git🔗
To add a working copy from a new remote location, click on the '+' button and enter the required information. The repository url can be any SVN or Git url. If credentials are already available in the saved credentials, this will be shown. If not, credentials need to be entered, and will be saved if checkout is successful.
The custom display name can be used to set a specific display name for all content from this repository (shown for the repository component). If not set, the shortest unique name for the repository will be selected based on the existing repositories where content is already checked out. If at least one working copy from this repository has already been checked out, the display name will be read-only and can not be edited. The new working copy will be grouped together with the existing working copies from the same remote location.
The branch/tag field (for Git only) can be used to check out a specific branch or tag. If left blank, the default branch is checked out. For SVN, the branch/tag is specified through the url. The revision field (for SVN only) can be used to check out a specific revision of the repository. If the field is left blank, the latest revision is checked out.
When clicking 'Add', a working copy of the repository is checked out/cloned to your user disk. This can take a while if the repository is large. A spinner is shown with the possibility to cancel the operation if desired. After checkout, the new repository is shown, with all its working copies visible as grey boxes.
For git, it is strongly recommended to work on your own branch to avoid conflicts with remote changes in everyday work. Any conflicts with remote changes are then handled only when changes are merged to another branch (e.g. main/master).
Check Status of Working Copies🔗
The revision number (for SVN) or branch (for Git) and the size of the working copy on disk are shown for each working copy. It is also possible to open the working copy in Visual Studio Code (VS Code) through the context menu when clicking the three dots in the grey box.
An icon next to the three dots indicates the current status of the working copy:
- An orange lock icon indicates that the status can not be fetched since credentials are locked ("locked"). Click on the lock icon on the top right corner to enter the master password and fetch the status.
- A red, strikethrough lock icon indicates that there are no credentials for this repository in the saved credentials ("no credentials"). Go to the credentials page to enter credentials for this repository to be able to show the status.
- A green check with arrows means that the working copy is up to date with the remote repository ("up to date"). No update is needed and there are no local modifications in the working copy.
- A pen and text icon indicates that there are local modifications in the working copy ("has local modifications"), e.g. from editing, adding, or deleting models in any library inside this working copy in Modelon Impact. These changes can be uploaded to the remote repository ("Push changes" for Git, "Commit changes" for SVN), or reverted through the context menu. To view the changes file by file, open the working copy in VS Code through the context menu. Hints on how to view differences in Visual Studio Code are available in the section Version Control in Visual Studio Code.
- A dark cycle arrow indicates that there are remote updates to this working copy ("has remote updates"), i.e. the working copy is not up to date with the remote repository. Updating to the latest revision is enabled through the context menu.
- A red exclamation mark with arrows indicates a conflict between the local modifications (my changes) and the remote updates to the repository (incoming changes) ("has conflicts"). The conflict can be resolved through the context menu using "Keep my changes" or "Keep incoming changes", or the conflicts can be edited and resolved manually using VS Code. Hints on how to edit conflicts in Visual Studio Code are available in the section Version Control in Visual Studio Code. There is also an option to revert all local modifications to the working copy.
Fetch Remote Updates🔗
When the status is "has remote updates", the context menu has an option "Update" that can be used to fetch the remote changes to the working copy. Note that there may also be local modifications to the working copy, and any conflicts with incoming changes will be shown only after updating. To inspect the working copy file by file before updating, open the working copy in VS Code through the context menu, see hints in the section Version Control in Visual Studio Code.
After clicking update, the status will be either "up to date", "has local modifications", or "has conflicts". If there are conflicts, these can be resolved through the options in the context menu, or by opening VS Code to edit and resolve the conflicts manually.
Upload Changes to the Repository🔗
When having worked with a version controlled model/library in Modelon Impact (added/modified/deleted models and/or packages), the working copy where the library is located will contain local modifications. These can be uploaded (committed/pushed) to the remote repository through the repository management page. The most convenient way of working is to open the Workspace configuration page from the Apps menu inside the workspace in Modelon Impact. This will show all version controlled libraries inside the workspace and their status. For the working copy for which to upload the changes, click the context menu (three dots) and select "Open in Repo Management". This will open the Repository Management page with the relevant repository and working copy selected.
To upload the changes, first, verify that the status is "has local modifications" (pen and text icon). If the status is a lock icon, credentials need to be unlocked or added first. If the status is "has remote updates", the remote updates need to be fetched first. If the status is "has conflicts", the conflict needs to be resolved first.
To inspect the changes, open the working copy in VS Code through the context menu. See hints on how to view the changes in the section Version Control in Visual Studio Code.
To upload the changes so that everyone with access to the repository gets access to them, click "Commit changes" (for SVN) or "Push changes" (for Git) in the context menu. A field will appear where a commit message can be entered. The changes are committed/pushed to the current branch.
Common practice is to set the commit message to a short description of the changes which are committed, and a development ticket number if relevant.
After uploading the changes, the status of the working copy should be "up to date", and the revision (SVN only) be updated to the latest.
Revert Changes in the Working Copy🔗
If wanting to discard all local modifications in a working copy, this can be done using "Revert changes" in the context menu for the working copy. This will revert any changes done to models that are already version controlled, but no local files will be removed from disk. The option is available when the status is "has local modifications" (pen and text icon) or "has conflicts" (red exclamation mark icon). Checking which files are modified can be done by opening the working copy in VS Code, see hints on how to do this in the section Version Control in Visual Studio Code.
After reverting the changes, the status of the working copy should be "up to date" or "has remote updates".
Solve Merge Conflicts🔗
If two or more users work on the same branch and make changes in the same files, merge conflicts may appear when updating the working copy, due to conflicting changes in the local working copy with incoming changes. This will set the working copy in a conflicted state, which is indicated by the "has conflicts" status icon for the working copy.
The conflict can be resolved using the options "Keep my changes" or "Keep incoming changes" in the context menu. "Keep my changes" will resolve the conflict by keeping your own full file for each file where there are conflicts with remote changes. This will result in the status "has local modifications", and your changes can then be uploaded to the repository if desired. "Keep incoming changes" will keep the full file from the remote repository for each file where there are conflicts.
To edit the conflicts manually, open the working copy in VS Code. In VS Code, open each conflicted file in the "Source control" view, select "Accept current" or "Accept incoming" for each conflict and then accept the conflicts as resolved when prompted. See more hints related to this in the section Version Control in Visual Studio Code.
SVN tree conflicts (e.g. two users adding a model with the same name) can currently not be resolved by the "Resolve" actions in the context menu. These conflicts have to be resolved in another tool (e.g. Visual studio code or a terminal).