A VIGO6 installation comes with a company COPP-archive (also called Signer archive). This archive has all the COPP-component types that the company uses. This means both PD-developed component types and component types that the company has created.
The VIGO6 workstation installation has a local archive. Types in the local archive are classified as; Draft, Development, Deleted, Tested, Approved, or Archived.
This enables the VIGO6-developer to develop COPP-component types and store them locally as draft types for instance.
Once you have tested a component, you can archive it to the company server. In effect, the editor tags the component with the identification of the owner, a timestamp, and the status “archived”.
The type is now visible and useable to all other VIGO6-developers in the company. Developers can get a local copy by refreshing their local archives. Further, the local copies will have the same GUID as the one on the company archive.
If you make any change to an archived COPP component type, VIGO6 will create a new version of the type. Only the owner of a component type can create a new version. The owner can change ownership of a component type to another VIGO6-user, who then becomes the owner.
GUID states
Draft and the shared draft
A type in the draft state is local. It means that you only have stored your type on your workstation. As a result, another user from your company can’t see the type. When you want to delete a type from the draft, save, right-click on the tab, and click “Remove selected GUID from the archive”. From the draft state, you can change the state to Shared Draft to share it with other people. Sharing doesn’t mean that they can make changes to the type, it only means that they can view and use the type. You can only make changes to the types you own.
Put your draft in the shared draft
To put a draft into the shared draft state: First, you select the user(s) you want to share your draft with. By right-clicking on the type, and press “Select draft user”, and choose a user. Afterward, you click on “Draft” -> “Push type and doc. to signer” -> “OK”. You have now backed up your type on the server and shared it with the selected user(s). When you make changes to the type, you can push them to the server again to back up again. You can also change users again, but you need to push the changes. If you don’t select any users when pushing to the shared draft state, it works as a backup. Restore the backup from the server to the PC workstation by the “Restore type and doc.” command.
Documentation
When you push to the shared draft, you take a snapshot of your type with documentation. It will not create a new version. This is good if you are still at an early stage, and you don’t want to create a lot of versions. However, it can also be a problem because you can’t create a steady version that you can return to. For that reason, you can move your draft or shared draft to development. It is always a good idea to create a changelog each time you create a new version of your type. It is especially important when you work in the shared draft state since each snapshot overwrites the last. As a result, you can’t go back and check the differences between the versions.
Sandpit
You can’t make changes to a type that you don’t own. If you are not the owner of a shared draft or any other type you can put the type in the sandpit state. In the sandpit state, you can make changes to a type as if it is your own draft state. For example, you could try to add a new feature or fix an error. Afterward, you could suggest changes to the owner.
When you are done, you restore the type and documentation. All your changes will be removed when you leave the sandpit state. If the original type has moved to another state, you will download the type in the actual state. When the owner has implemented the changes, you can change to the new version. You can’t push a type with type references in the sandpit state. So use it with caution.
Delete
The only way to delete a type after the draft is through the Delete state. It is a state because you move the type to the deleted state. The type will be there for a certain time before it is deleted. If the server hasn’t deleted your type, you can put it back to the state it came from. The only type that you can’t delete is a type in the archived state.
Development
When you move a type to the development state, the type will be in version 1. You can’t make changes to version 1. In other words, it is locked. If you want to make a change, you right-click on the type and click “Create new version of type”. The new version will be in the draft state, and you can make changes. When the version is ready for development, you push the new version to the development state, and now both versions are in the development state. You can switch between the versions by right-clicking on the type and click on “open previous version” or “open next version”.
If you use a type in the development state in your project, and the owner creates a new version, you can’t know for sure that the new version will have the same functionality as the one you use in your project. For example, if you have a connector to a type in version 5, but you actually use the type in version 6, the editor will give you a warning. The reason is, that you can’t know if the type has the same interface in version 6. If you want that certainty – use an archived version of the type.
Tested and approved
You can’t put an approved type in the sandpit state or the deleted state, but you can move a type between the states tested and approved. You can change a type to the tested state when another person should test it. If that person, or another, approves it, you can move it to the approved state. If someone finds an error, it can be moved back to the tested state. In the end, if the type is ready, you can move it to the archived state that is the final state.
Archived
After you have put a type in the archived state, you can create a new version, but you can only add functionality to it.
The type itself can’t be deleted either. This means that you need to be very careful about changing the state of a type to archived. In effect, you don’t get type reference warnings when you use archived types, because you can be sure that the types still match after you change to a new version of the archived type.
The compromise is a trade of flexibility and speed in development for certainty and stability.
Yellow means that the type is local. Green means that you have backed the type backed up on the server. Note: You can only change the state from the shared draft to the sandpit if you are not the owner of the type.
« Back to Glossary Index
