Parent page: Managed Projects
This document takes a look at working with managed projects from within Altium NEXUS, including:
There are two ways in which a managed project can be created from within Altium NEXUS:
The following sections take a closer look at these two avenues of creation.
A new managed project can be created from within Altium NEXUS using the Create Project dialog (File » New » Project):
The Create Project dialog includes further options:
Projects\<ProjectName>). Click the button to browse to and select a different server folder, if required.
*.PrjPcb), and can be edited in Altium NEXUS. Both parameter types may be used as Special Strings in Altium NEXUS - access from the Properties panel with a placed Text String selected in the design workspace. Parameters defined for the project can also be viewed on the Parameters and Server Parameters tabs of the Project Options dialog (Project » Project Options).
With the project defined as required, click the button. The new project structure will be created in the specified local and Workspace (server) folders. The project will be opened in the Projects panel, which will show the project and its constituent documents as being Scheduled for addition, denoted by blue cross icons ().
Right-click on the project in the Projects panel and choose the Commit Project command or the Version Control » Commit Whole Project command. You will be presented with the Commit to Version Control dialog. Select the files you wish to commit to the Workspace's Versioned Storage design repository and click the button. Once added, the Projects panel will reflect the fully synchronized state that exists between the files in the remote design repository (in the Workspace) and the local (working copy) repository - as indicated by the associated icons.
In addition, an entry for the project will appear on the Projects page of the Workspace's browser interface.
For those unfamiliar with Git repositories, or for those just wanting to get their local design changes into the Workspace, using the button in the Commit to Version Control dialog is the cleanest and most streamlined approach.
However you also have the option to Commit to your local Git repository, ahead of pushing changes to the remote Git repository (Versioned Storage) in the Workspace. To do so, select the Commit command as above, and in the Commit to Version Control dialog choose the Commit option from the button drop-down menu. The changes will be saved to the local Git repository for that project, and the state of the files - as reflected in the Projects panel - will become Ahead of server ().
These locally saved changes can be sent to the remote Git repository in the Workspace at a later time by executing a Push command. This can be performed in a couple of ways:
Once pushed, the Projects panel will reflect the fully synchronized state () that exists between the files in the remote repository (in the Workspace) and the local (working copy) repository.
You can also make an unmanaged project (regular project, or a project currently under version control) available to the Workspace - essentially 'registering' the project with the Workspace and creating a 'mirror' of it. This allows you to enjoy the collaborative features available through the Altium 365 platform, while keeping your original project right where it is. To do this, open the existing unmanaged project as normal in Altium NEXUS, then right-click on its entry in the Projects panel and select Make Project Available Online from the context menu, giving access to the Make Available Online dialog.
Use the Make Available Online dialog to change the project Name and add a Description. By default, the name will be that of the original project.
Check the Enable Formal Version Control option to add the project under the Workspace's own built-in VCS (Git). This option is unchecked by default, where the project files will simply be stored in the Workspace for basic access and to enable sharing with others for viewing and commenting only - a less formal Simple Sync as it were. It is recommended to enable formal version control, as by doing so you will have access to the maximum functionality offered through, and by, the Workspace and the Altium 365 platform.
Click the Advanced link to expose the Folder field. This field is used to specify where the folder for the mirrored project - within the Workspace's folder structure - is to be created. The default path for new projects is specified on the Admin - Settings - Projects page of the Workspace's browser interface (by default, this will be
Projects\<ProjectName>). Click the button to browse to and select a different server folder, if required.
With the properties for the mirrored project defined as required in the Make Available Online dialog, click OK. Projects that have been made available online - in the Workspace - will be shown in the Altium NEXUS Projects panel as follows:
The mirrored project will subsequently be available from the Projects page of the Workspace's browser interface.
Where an unmanaged project is made available online to the Workspace using the Simple Sync approach (not using the Workspace's formal version control), the current state of the synchronization between local and server-side projects is presented in the Projects panel through a range of icons. These icons, and their meaning, are as follows:
|Synchronized||The local project and the mirrored project in the Workspace are synchronized.|
|Sync-in-progress||Changes made to the local project are being synchronized to the mirrored project in the Workspace. For a local project not under external VCS, this occurs when saving a local file. For a local project under external VCS, this occurs when saving and committing local file changes to the external design repository.|
|Project is Read-only||The project has been shared with you, but you have Read-only access to it. Under the Simple Sync methodology, the design project can be edited by a single person only (the owner of that project - the one who made it available online to the Workspace).|
|Not Synchronized||Changes have been made locally, but these have not been synchronized yet with the mirrored project in the Workspace. This can happen, for example, when the same project is open for editing by the owner/author on two computers (PC1 and PC2). On PC1, the Workspace is subsequently disconnected. On PC2, connection to the Workspace remains and changes are made. On saving the local file(s) the project remains unsynchronized. If you attempt to close the project on PC2, the Closing unsynchronized projects dialog will appear alerting you to this fact. If you choose to close the project, changes will not be available on PC1. To remedy the situation, disconnect from and then reconnect to, the Workspace on PC2. The project will be synchronized with the Workspace. The synchronized data will be reflected on PC1 once the Workspace is connected there too.|
There is a conflict between the data for the local project and the data for the mirrored project in the Workspace. This can happen, for example, when the same project is opened for editing by the owner/author on two computers (PC1 and PC2). On PC1, the project is opened and the Workspace subsequently disconnected. Changes are then made and local files saved. Later, on PC2, the same project is opened and, while still connected to the Workspace, changes are made and saved. Later still, connection is made to the Workspace back on PC1. A conflict exists because there are changes locally on PC1, but the Workspace contains the updated data from changes made and synced on PC2.
To remedy the situation, on PC1 right-click on the project and choose the Resolve Conflicts command. The Resolve Conflicts dialog will appear. You have the option to Use Server files (the data from the mirrored project in the Workspace will be used and local modifications will be lost), or Use Local files (the data from the local project will be used and synced to overwrite the current data for the mirrored project in the Workspace).
As mentioned previously, your unmanaged designs may already be tracked under an existing, external version control system (Git, SVN, EPDM, etc...). You can continue using this setup as before, and simply make the designs available to the Workspace by registering them with that Workspace - using the Make Project Available Online feature.
In this mode, every time you make changes to a design and commit those changes to your external VCS repository, that design data will be mirrored to the Workspace in the background, and all needed processing will be performed as usual - preview, where used etc. There are some limitations to be aware of however:
Out Of Dateand can be corrected using the version control Update command.
In some cases, functionality delivered through the Altium 365 platform - or more specifically an Altium 365 Workspace - can only be experienced by having your project fully managed and stored under the Workspace's native VCS (within its Versioned Storage Git repository). What you can do is create a snapshot of your project, disconnecting it from external VCS and from the Workspace (if already made available there), and then make it available to the Workspace again, but under the Workspace's VCS - starting afresh as it were. To do so, follow the procedure below:
Using the GitHub platform as an external version control system (VCS) is a popular way to host and share design projects, and is easily integrated with an Altium Workspace through Altium NEXUS. As described above, the existing external VCS arrangement is synchronized with an Altium Workspace which allows you to benefit from its advanced data management and collaboration features.
How you normally work with GitHub itself will vary depending on company practices or simply the Git tools you have at hand. In general however, a design project is created in a local Git repository and then Pushed to a GitHub (remote) repository, or an existing project is Cloned to a local repository from GitHub. Once in the local Git repository, the project can be opened in Altium NEXUS and mirrored to an Altium Workspace (Make Project Available Online), as outlined above.
While there is a range of data transfer protocols offered by the Git VCS, Altium NEXUS currently supports the HTTP/HTTPS protocol only for connections between a local Git repository and its remote master repository. In practice, the applied protocol is set by the URL prefix specified for the remote repository connection –
git://<remote repository>, and so on.
GitHub supports both the SSH and HTTPS protocols, and recommends using HTTPS URLs for connections.
► See Which remote URL should I use? on GitHub for more information.
If your external VCS system is bound to a protocol other than HTTPS, such as a GitHub SSH connection, this will be preset in a repository that has been cloned from the remote. As this protocol is incompatible with Altium NEXUS, an error will be thrown when attempting to integrate the project with an Altium Workspace. If you are unsure of the remote URL protocol that is used for a local Git repository, this can be checked using the
git remote - v command.
The repository can be reconfigured for a different URL, such as the HTTPS protocol to enable compatibility with Altium NEXUS, by using the
git remote set-url <name> <URL> command, where the URL's prefix specifies the protocol type.
Once an unmanaged project has been made available online, controls over its online availability and synchronization are provided through the General tab of the Project Options dialog.
Use the options available in the General region of the tab to make changes to the name of the project and/or its description. These affect the mirrored project within the Workspace only - the name of the local project is not changed.
In the Online Availability and Synchronization region of the tab, the Enable Formal Version Control option reflects the current style of online availability:
Use the option to change between these two as desired.
Should you wish to stop the synchronization between your local project, and the managed incarnation of it that was made available in the Workspace, click the button. The Turn off project synchronization window will appear. Click on the Unlink option, then click OK back in the Project Options dialog. The local project will no longer be associated with the project in the Workspace.
This is reflected in the Projects panel after saving the local project, by the project being presented under the active Project Group (*.DsnWrk), rather than as an entry under the active Workspace. A save is required since the links to the project in the Workspace are removed from the project file.
The project in the Workspace remains untouched - it is not removed by this action.
You can always make the unmanaged project available online again. The General tab of the Project Options dialog will present the button, with which to access the Make Available Online dialog. Refer back to the section Make an Existing UnManaged Project Available Online for more information.
Related page: Sharing a Design from within Altium NEXUS
Once a project is managed (available in the Workspace), you'll want to determine which users can actually access that project. This is done by sharing the project, or rather, by configuring its access permissions. Remember that a managed project - newly created or made available in the Workspace - is shared, by default, with the following:
Controls for sharing a design from within Altium NEXUS can be found in the Share dialog - accessed by clicking the button at the top-right of the main application window.
The following levels of sharing are supported from within Altium NEXUS:
To work on a managed project, you effectively check it out as a local working copy. This is performed directly from within Altium NEXUS using the File » Open Project command. The Open Project dialog will appear, from where you can choose which managed project to open from your Workspace (when connected to a Workspace, that Workspace will appear in the Locations region of the dialog, distinguished by the icon, and appearing with the name given to the Workspace). Only those managed projects that have been shared with you (you have permission to access) will be listed.
Once opened, the project will appear under an entry for the Workspace, in the Projects panel.
To clone a managed project from within Altium NEXUS, right-click on the entry for the project in the Projects panel and choose the Clone command from the context menu. Use the Clone Project dialog to determine the Project Name, Description (which is not pre-populated), the Folder path (within the Workspace), and the Local Storage path (to the working copy).
Valid students can get their very own 6-month Altium Designer Student License for FREE! Just fill out the form below to request your Student License today.