Working Copies - Synchronise Projects on Multiple Servers

Modified on Tue, 26 Mar at 8:18 AM

Working Copies are “linked copies” of a project that can be worked on independently of the original project, while providing a facility to easily publish changes back to the original project when desired.



Typically you’d use this in a team when editing mission-critical projects/reports on a production server, working on a separate dev/test server or using a local Omniscope installation on your desktop.


We use two different terms within the user interface to explain to end user:


  • Original project: This is the project that is hosted on your production server which you don't want to modify directly. This would typically be your production projects/reports.

  • Working Copy: This is the term we use refer to the project that allows you to publish it's changes back to master project. This would typically be individual copies of the master project hosted on your development or local installations.


Sometimes it is useful to work on a copy of a project, without affecting the original until these changes are finalised. For example one can have a dashboard in a production environment, which gets regularly updated when the new features are fully implemented.


In this scenario one can identify a "original copy" - the file used in production, and a "working copy" - a copy of the file used while implementing the new features without affecting the original.


For use cases like these Omniscope EVO offers functionality that will manage and automate the process of updating the 'master report'.


A working copy is linked to the original master report and used for any development and updates. Once the changes have been finalised, the working copy can be published back to the master with a simple click. It is also possible to discard any local changes (e.g. if the changes are not approved) and restore the working copy to be the same as the master.


There are scheduler actions available from 2024.2 builds to automate pushing your changes to original project. These actions are project actions and are available from the Project actions menu.


Licensing / Permissions


NOTE: Please note you need to have Omniscope Evo Business or Omniscope Enterprise license on your production server to use this feature. Local installations where the working copy is being created can be on Omniscope Pro licenses.



A new permission called "Project Publisher" has been added. This permission determines whether the users in the group are allowed to create a working copy for a project, publish their changes to the master copy or update their local working copy from the master copy. 


A group will be able to change a project only via a working copy, and reduce the risk of accidental changes to a live original project.


By default this permission is turned off. If you wish to allow working copies feature for your users you need to turn it on.


If you want to create a setup for your users where they can only update the original projects on your production server through working copies feature and never directly. You want to turn off project editor permission, but instead give them project publisher permission.


For more information about Omniscope Evo permissions management you can read this article.


Creating a working copy


To create a working copy navigate to the directory where the original file is located in the list directory app, click on the three dots menu an click on "Make a Working copy".





The dialog that appears will display a url link (http://lava.omniscope.me/Folder/File.iox/ in the example). Copy the link, and move to the "working environment": this can be another Omniscope instance, or a different location on the same Omniscope instance. 




In the new environment, in the list directory app, click on the create working copy button and paste in the link you copied from "Make a Working Copy" dialog, and then click "Create".




Create a working Copy here button.

 


When you click on "Create" button you will be prompted to authenticate with the server hosting the "original" project.  

For example, when creating a working copy of a project in production on a personal laptop, the credentials should be the ones of the production environment (as opposed to the ones of your local environment) because Omniscope needs to create a copy from the production environment and that request needs to be authenticated.




Once you have successfully authenticated and working copy has been created you will see a success message. After that your working project will automatically open.

 






It is now possible to work on the working copy without affecting the original copy until the changes are finalised.


Publishing local changes


Once the modifications on the working copy are complete, it is possible to push the working copy version to the master copy location. This can be done by clicking on the "Push" button.


NOTE: If the master project has changed since you created your working copy, and you attempt to push, then you will be notified of this. You will then have an option to either revert your local copy or override the original copy with your changes.





Warning: this action will completely replace the original copy with the working copy.


After publishing the master copy will be the same as the working copy.



Update/Revert


It is possible to discard any changes on the working copy and update the local working copy to match the original copy.


To revert local changes and/or get the most recent version of the master project you need to open the local working copy project, and click on "Update/Revert.." from the three dots menu.





Warning: Reverting a project will cause any local changes to be lost.



Detaching the Working Copy


Once the working copy has been created it is possible to detach it from the original copy, and convert it to a 'local project'.


To detach a working copy from the original you should click on the "Detach" option from the three dots menu.


Once the project has been detached it will no longer be possible to push local changes, or revert to the original copy.

Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article