What's This Altium 365 / NEXUS / Concord Pro Vault         Thing All about?

The Altium 365 / NEXUS / Concord Pro vault is a database designed by Altium to store and manage components, templates, and documents. The original architects of the Vault saw that there was a wall between product designs and supply chain management. They wanted to build a system that would manage this better.

The frustration that many have with the Altium 365 / NEXUS / Concord Pro vault is that they do not understand the methodology that drove the development of the Vault. Yes, the Vault saves documents and components. Yes, the Vault is used for life cycle management. Yes, the Vault is used for revision control. The big question is: How does all of this fit and work together?

We need to clarify something from the outset. The methods to handle components in the Altium 365 / NEXUS / Concord Pro vault are different from handling projects. This has to do with the time needed to create a project versus a library component. We normally don't capture component while it is being developed. For example, we don't upload half a symbol (even if it is divided into a multi-module representation) and then get back to it days or weeks later to complete it. We upload the symbol when we have what we believe to be a completed symbol. Granted, we may need to make changes to the symbol to correct something, but the components' changes are generally capturing what we believe to be complete and correct.

This philosophy is not necessarily true for designs. Designs can take weeks or months. Therefore, we may want to capture the design as we progress through the design process. The method of capturing the design varies depending on whether the design is in progress or completed.
It is important to understand the difference between a production version control system and a prototyping version control system. By understanding this, you will see why Altium makes Subversion (known as 'SVN') available within the Altium 365 / NEXUS / Concord Pro vault.

The purpose of a version control system is to record the history of the design. In a production version control system, it is a matter of capturing the end product. Whatever it took to get to the end product does not matter. It's about gathering all of the key files used to make the design and putting them into a place that safeguards the files from being lost or modified.

This is effectively what the Altium 365 / NEXUS / Concord Pro vault does for projects. The user declares a revision in the Vault and, through a release process, takes the projects' current files and puts them into a safe place. These files can be viewed in Altium, but they cannot be modified. If a new revision is desired, the user must download these files, modify the downloaded files, declare a new revision in the Vault, and then release the documents into the new revision.

As you can imagine, this production revision control method is a formal process, and it can take some time to complete. This is great when the project is complete, but what about capturing the project as it is being developed? This method would be tedious, at best.

When we are designing, what we need is a way to take capture the design quickly. This is the concept of a prototyping version control system. One can capture the design as frequently as they see fit. SVN is a perfect example of a prototyping version control system. It is rather easy to commit a change to the repository. More importantly, the user relies on the written comments made when pushing the design into the repository. The revision number means very little in SVN.

So then, why bother with the Altium 365 / NEXUS / Concord Pro vault when one can use SVN? The biggest reason is that anyone can commit a new set of files after the product has been completed. Unless the comments are clear that a certain commit was the one sent to manufacturing, determining which set of files are the ‘golden standard’ can be a daunting task long after the fact.

So then, why bother with SVN? If the user has provided good comments upon committing the file, it allows the designer to go back to earlier stages of the project if this is warranted. We are often asked to add something, then remove it, and then add it back in again. It also allows us to backtrack to an earlier design if we had gone in a bad design direction.

To summarize the difference, think of a wedding photographer. They may have 2 cameras. The first camera is used to take formal photos of the bride, groom, and family. These are photos that require a bit of time to organize and shoot. This would be similar to a production version control system.
The second camera can take pictures on the fly, especially at the reception when much is going on. The idea is to capture the event in pictures. This would be analogous to a prototyping version control system.

In recent years, Altium added SVN to the Altium 365 / NEXUS / Concord Pro vault. On the surface, this seems a bit odd. Why would a version control system need a version control system? This is really not the case; think of the SVN and Vault as two separate entities in the software. Altium wanted to better control the interaction between SVN and the Vault, especially during the project release process from the SVN repository into the Vault.

The SVN user community does release major updates from time to time. Those changes can break the programming interactions between Altium and the SVN engine. Most so, it can take Altium several months to incorporate the new changes. Having the SVN built into the Vault can avoid those possible disruptions. As a side note, Altium also uses this configuration to better assist in PCB collaboration, allowing 2 or more users to work on the same layout simultaneously. It also assists with the real-time interaction between Altium Designer and Solidworks.

More Information