Ce type d’événement n’est pris en charge que pour un projet entièrement géré et stocké sous le VCS natif du Workspace (dans son dépôt Git
Versioned Storage). Pour un projet local rendu disponible dans le Workspace Altium 365 mais non placé sous contrôle de version formel — utilisant ainsi la méthodologie Simple Sync — vous ne verrez aucun événement de validation lié au VCS dans la chronologie de l’historique. Pour obtenir ces informations, vous pouvez changer le mode de disponibilité en ligne en activant l’option
Version Control dans l’
onglet General de la boîte de dialogue
Project Options. Cela place le projet sous le VCS natif du Workspace.
Pour un projet rendu disponible dans un Workspace Altium 365 mais déjà sous contrôle de version externe, vous ne verrez pas non plus d’événements de validation liés au VCS dans la chronologie de l’historique. Utilisez votre client de contrôle de version externe pour examiner l’historique de contrôle de version du projet. Vous pouvez également basculer effectivement vers le VCS natif du Workspace. Vous pouvez créer un instantané de votre projet — de la manière la plus efficace et la plus propre à l’aide de
Project Packager d’Altium Designer. Cela le déconnecte du VCS externe et du Workspace (s’il y a déjà été rendu disponible), après quoi vous pouvez à nouveau le rendre disponible dans le Workspace, mais cette fois sous le VCS du Workspace — en repartant pour ainsi dire de zéro. Pour des informations détaillées sur la procédure, consultez
Passer d’un VCS externe au VCS natif du Workspace.
Chaque fois que vous validez un projet dans le Workspace (lorsque le projet est géré dans le dépôt Git Versioned Storage interne du Workspace), une vignette d’événement Project Committed est ajoutée à la chronologie. La personne ayant effectué la validation (Save to Server) est indiquée par son nom (et sa photo), ainsi que la date et l’heure. Si un commentaire a été ajouté au moment de la validation et envoyé — à l’aide de la boîte de dialogue Commit to Version Control — il sera également affiché dans la vignette.
Si le projet était un projet local non géré qui a ensuite été rendu disponible en ligne, alors la description saisie dans la boîte de dialogue
Make Available Online sera utilisée à la fois dans la vignette d’événement
Project Created et dans la vignette d’événement initiale
Project Committed, puisque la validation du projet est effectuée dans le cadre de sa mise à disposition en ligne — à condition bien sûr que l’option
Version Control ait été activée.
Exemple de vignette d’événement initiale Project Committed.
La vignette prend également en charge et présente des informations de comparaison de conception, montrant des informations plus détaillées sur ce qui a changé entre la validation actuelle et la précédente. Les éléments pris en charge comprennent les fichiers, les composants, les nets, les variantes et la structure du PCB. La section de comparaison de la vignette résume les différents éléments affectés par l’événement de validation, regroupés selon les états suivants :
– élément ajouté.
– élément supprimé.
– élément modifié.
En cliquant sur le contrôle 
dans la vignette, cette section de comparaison se développe pour présenter les éléments affectés par leur nom.
Utilisez les contrôles
Show More et
Show Less disponibles pour examiner la liste complète de chaque type d’élément. Cliquez sur le contrôle
dans la vignette pour revenir à l’affichage récapitulatif.
Cliquez sur le contrôle 
dans l’angle supérieur droit de la vignette pour accéder à un menu contenant les commandes suivantes :
-
Download Sources - uà utiliser pour télécharger et ouvrir cette révision spécifique du projet PCB ou Harness dans le panneau Projects. Le nom du projet inclura la date et l’heure auxquelles cette révision a été validée. Notez que cette révision est en lecture seule ; vous pouvez la consulter mais pas la modifier.
Vous pouvez ouvrir (en consultation uniquement) n’importe quelle révision spécifique du projet — directement depuis la vignette d’événement Project Committed correspondante pour cette révision.
-
Compare: Schematic to, PCB to, BOM to – vous permet de comparer les données Schématique, PCB ou BOM du projet PCB dans ce commit avec celles d’un autre commit ou événement de publication. Utilisez le sous-menu pour comparer avec le commit précédent ou sélectionnez parmi toutes les publications et tous les commits possibles. Une fois les données choisies pour la comparaison, les résultats sont présentés dans la vue des différences associée, qui s’ouvre dans un nouvel onglet de votre navigateur par défaut. Pour plus d’informations, voir Design Data Comparisons (Altium 365 Workspace, Enterprise Server Workspace).
-
Create Tag – ajoute une balise unique, nommée de façon personnalisée, à n’importe quel commit d’un projet de conception (et uniquement lorsque ce projet est stocké dans un Workspace sous son système interne Git VCS). Vous pouvez créer une balise uniquement pour un commit déjà enregistré dans le Workspace. Après l’exécution de la commande, la boîte de dialogue Create Tag s’ouvre. Saisissez la balise souhaitée puis cliquez sur Create.
Lorsqu’une balise saisie contient un caractère non autorisé, l’icône 
apparaît dans la boîte de dialogue Create Tag. Survolez l’icône pour afficher une « aide » indiquant quels caractères sont autorisés, à savoir les lettres, les chiffres, le point ('.'), le tiret ('-'), le dièse ('#') et le trait de soulignement ('_') ; mettez à jour la balise si nécessaire.
Une fenêtre d’information s’ouvre pour vous avertir si le nom de la balise contient des caractères non autorisés. La balise ne sera pas créée tant que ces caractères non autorisés n’auront pas été supprimés.
Si le projet comporte des commits qui n’ont pas encore été poussés, la boîte de dialogue Save To Server s’ouvre pour vous demander si vous souhaitez effectuer un push. Si le commit est poussé, la boîte de dialogue Create Tag s’ouvre.
Lorsque le projet est publié à l’aide du Project Releaser et que son dernier commit n’a pas encore de balise, une balise sera automatiquement attribuée à ce dernier commit. Cette balise sera de la forme RELEASE_<RevisionID>, où <RevisionID> est le numéro de révision des sources du projet publié (A.1, A.2, etc.), par exemple, RELEASE_A.3.
Pour renommer ou supprimer une balise, cliquez sur 
puis survolez l’entrée Tag . Une boîte de dialogue s’ouvre dans laquelle vous pouvez saisir le nouveau nom de la balise. Si Remove est sélectionné, la balise est supprimée immédiatement.
La commande
Create Tag est également accessible en cliquant avec le bouton droit sur le nom d’un projet ou d’un document dans le panneau
Projects , puis en choisissant
History & Version Control » Create Tag pour créer une balise pour le dernier commit.
Remarques :
-
La prise en charge des balises n’est pas disponible pour le contrôle de version externe.
-
Une seule (1) balise peut être créée par commit.
-
Make a copy – permet de créer une copie à partir de cette révision spécifique du projet. La boîte de dialogue Create Project Copy s’ouvre, dans laquelle vous saisissez un Project Name (par défaut, il s’agira du nom du projet d’origine avec le suffixe ' - Copy'), Description (qui n’est pas prérempli), le chemin Folder (dans le Workspace) et le chemin Local Storage (vers la copie de travail). Le projet sera créé et une vignette d’événement Project Copied sera ajoutée à la chronologie.
Le
Folder du Workspace sera, par défaut, le même dossier que celui dans lequel le projet d’origine est stocké. Cliquez sur
pour ouvrir la boîte de dialogue
Choose Folder (une version simplifiée du panneau
Explorer) afin de modifier le dossier selon vos besoins. Le
Local Storage sera, par défaut, défini pour utiliser l’emplacement indiqué sur la page
System - Default Locations de la boîte de dialogue
Preferences. Cliquez sur
pour ouvrir une boîte de dialogue Windows standard permettant de modifier cet emplacement selon vos besoins.
-
Revert to – utilisez cette commande pour revenir aux données de cette révision spécifique du projet. Les données des documents source du projet dans cette révision spécifique écrasent les données de votre copie de travail locale du projet. En pratique, le projet est momentanément fermé puis rouvert avec ces données restaurées. Si vous souhaitez finaliser le retour en arrière et faire de ces données la Head Revision (version actuelle), vous devez valider et pousser le projet vers le Workspace.
Vous pouvez revenir à n’importe quelle révision spécifique du projet directement depuis la vignette d’événement Project Committed correspondante pour cette révision.
Après être revenu à une révision spécifique et avant de valider, vous pouvez restaurer votre copie de travail locale à la dernière révision à l’aide de la commande Revert to associée à la dernière vignette d’événement Project Committed sur la chronologie.
Une vignette d’événement
Project Committed est physiquement reliée au tronc principal de la chronologie par une ligne de connexion bleue continue et un nœud plein :
. La dernière révision du projet (c’est-à-dire le dernier commit) se distingue par un remplissage blanc de son nœud :
.
AI-localized