Using External Version Control

L’une des plus grandes forces d’un environnement de création et d’édition électronique est la facilité avec laquelle vous pouvez créer et modifier un fichier. Cette capacité permet de capturer, explorer et faire mûrir rapidement des idées, mais elle signifie aussi qu’il peut être difficile de suivre les modifications apportées à des fichiers précieux tels que le code source et les données de conception électronique.

La nécessité de suivre les modifications apportées à un fichier, combinée au besoin d’une solution systématique pour gérer les sources capturées sous forme électronique, a conduit à l’émergence des systèmes de contrôle de version (VCS). Les systèmes de contrôle de version sont des outils logiciels qui sont non seulement capables de conserver un historique des différentes versions d’un fichier, mais qui permettent également d’ouvrir n’importe quelle révision de ce fichier, ainsi que de comparer les modifications effectuées entre deux versions quelconques du fichier. Un VCS s’intègre généralement au système d’exploitation (OS) local en fournissant des fonctions et opérations de gestion de versions supplémentaires pour les dossiers et les fichiers.

Les systèmes de contrôle de version peuvent fonctionner de manière totalement indépendante de l’environnement de création et d’édition utilisé pour créer un fichier. Ils proposent généralement une interface qui vous permet d’ajouter puis de valider des fichiers dans une zone de stockage centrale appelée dépôt, une fonction de checkout pour copier un fichier du dépôt vers un dossier de travail, une fonction de commit pour réintégrer dans le dépôt les modifications apportées, une méthode de journalisation des informations relatives à une modification, et bien plus encore.

Ces fonctionnalités se retrouvent dans des extensions du shell Windows telles que le client Tortoise et sont également incluses dans Altium Designer lui-même. Les opérations VCS peuvent être effectuées dans l’environnement Altium Designer sans qu’il soit nécessaire d’accéder au système de fichiers de l’OS.

Il est utile de comprendre la terminologie utilisée avec les systèmes de contrôle de version. Même s’il existe de nombreux systèmes, ils utilisent généralement tous des termes similaires pour décrire leurs fonctionnalités.

Notions essentielles du contrôle de version

Altium Designer prend en charge les systèmes de contrôle de version (VCS) Subversion (SVN) et Git. Comme il prend en charge ces systèmes en interne, il donne accès aux commandes courantes de gestion de fichiers SVN/Git telles que Commit, Update, etc., dans Altium Designer, ainsi qu’à des capacités supplémentaires de Subversion, comme la possibilité de créer un dépôt SVN. Cela s’intègre aux fonctionnalités de comparaison de schémas et de PCB, ce qui permet de comparer rapidement et d’identifier facilement les différences entre deux révisions d’un schéma ou d’un document PCB et, pour les conceptions PCB, de résoudre les conflits de révision simultanés.

L’approche de base pour travailler avec un système de contrôle de version (VCS) consiste à accéder, depuis un dépôt, à une copie des fichiers de projet sur lesquels vous souhaitez travailler, à modifier les fichiers dans Altium Designer, puis à « valider » les fichiers modifiés dans le dépôt. L’interaction avec le dépôt s’effectue via une interface de système de contrôle de version, qu’Altium Designer intègre dans son panneau Storage Manager et son panneau Projects.

La clé du fonctionnement d’un système de contrôle de version réside dans le fait qu’il surveille l’état des fichiers auxquels on a accédé depuis le dépôt, via un dossier de travail, et suit donc la révision en cours de traitement ainsi que son éventuelle modification. Bien que le résultat soit le même, l’organisation du dépôt et des fichiers de travail diffère selon les types de systèmes de contrôle de version – Git ou SVN.

VCS Git

La figure ci-dessous illustre le concept d’un dépôt Git distant partagé contenant une séquence de révisions de fichiers de conception (jusqu’à la révision 5), dont le contenu a été copié dans un dépôt Git de travail local – généralement en clonant le dépôt distant ou en récupérant ses données dans le dépôt de travail. Lorsque les fichiers du dépôt de travail sont ouverts dans l’environnement Altium Designer, Altium Designer reconnaît qu’un fichier de projet est sous contrôle de version Git, son état actuel de contrôle de version étant affiché à la fois dans le Storage Manager et le panneau Projects.

► Consultez la page Contrôle de version basé sur Git pour plus d’informations.

VCS Subversion

La figure ci-dessous illustre le concept d’un dépôt Subversion contenant une séquence de révisions de fichiers de conception (jusqu’à la révision 5), avec la dernière copie extraite (File » Check Out) dans un dossier de travail. Lorsque les fichiers du dossier de travail sont ouverts dans l’environnement Altium Designer, Altium Designer reconnaît qu’un fichier de projet est sous contrôle de version SVN, son état actuel de contrôle de version étant affiché à la fois dans le Storage Manager et le panneau Projects.

► Consultez la page Contrôle de version basé sur SVN pour plus d’informations.

Dans les deux systèmes VCS ci-dessus, le lien entre le dépôt source et l’emplacement de travail est référencé dans la base de données VCS de ce dernier (dans le sous-dossier système .svn ou .git).

Lorsque des fichiers de travail VCS sont ouverts dans Altium Designer, le menu contextuel accessible par clic droit dans le panneau Storage Manager (et le panneau Projects) vous permet d’effectuer des actions VCS standard, telles que la validation d’un fichier modifié dans le dépôt central (SVN) ou le dépôt de travail (Git).

Accès au contrôle de version

Dans Altium Designer, les actions liées au VCS peuvent être effectuées via les panneaux Projects et Storage Manager, ce dernier offrant un accès direct à des commandes et informations VCS supplémentaires. Les panneaux sont renseignés avec les documents du projet et leur état VCS associé lorsqu’ils sont ouverts dans Altium Designer.

Les panneaux peuvent être ouverts depuis le menu du bouton en bas à droite de l’espace de travail, ou depuis le menu principal View » Panels.

Panneau Projects

Le panneau Projects affiche tous les projets actuellement ouverts dans Altium Designer, ainsi que leurs documents constitutifs et l’état de contrôle de version associé à chaque fichier.

L’état VCS des fichiers dans le panneau est indiqué par une série d’icônes correspondant à des conditions spécifiques détectées par le système de contrôle de version. L’état de chaque fichier est, en termes généraux, relatif à son équivalent existant sous contrôle de version dans le dépôt lié. Les commandes VCS du panneau Projects sont accessibles depuis l’option Version Control du menu contextuel obtenu par clic droit dans le panneau.

Icônes de contrôle de version telles qu’elles apparaissent dans le Projects panneau

► Consultez la page panneau Projects pour plus d’informations.

Panneau Storage Manager

Le panneau Storage Manager offre une vue détaillée du document actif du point de vue du stockage des fichiers et donne accès à la fonctionnalité d’historique local du document ainsi qu’à l’état/aux commandes du contrôle de version.

L’état VCS des fichiers dans le panneau est indiqué par une série de descriptions et d’icônes correspondantes liées à des conditions spécifiques détectées par le système de contrôle de version. L’état de chaque fichier est, en termes généraux, relatif à son équivalent existant sous contrôle de version dans le dépôt lié.

Le panneau Storage Manager

Les commandes VCS du panneau Storage Manager sont accessibles depuis le menu contextuel obtenu par clic droit. Pour effectuer une action VCS sur un fichier spécifique, cliquez avec le bouton droit sur son entrée dans le panneau et sélectionnez la commande souhaitée – par exemple, Commit, Update, Resolve conflict, etc.

L’historique des révisions du fichier sélectionné et l’historique local du document peuvent être consultés dans la section inférieure du panneau, ou sous la forme d’une chronologie globale des événements si vous passez en « vue classique » – Switch to Classic View dans les options du clic droit. Le numéro de révision indiqué s’incrémente à chaque commit VCS, la première révision (Revision 1) correspondant à la création des dossiers du projet VCS, avant l’ajout des fichiers.

► Consultez la page panneau Storage Manager pour plus d’informations.

État du contrôle de version

Pour les panneaux Projects et Storage Manager, l’état VCS actuel de chaque fichier sous contrôle de version est affiché avec son entrée dans le panneau.

Le système de contrôle de version surveille et compare essentiellement les fichiers du dossier de travail à leurs équivalents dans le dépôt de conception. Altium Designer demande et échange des informations avec le système de contrôle de version via son interface VCS, puis réagit en conséquence aux états comparatifs des fichiers. En pratique, cela se manifeste dans les icônes de fichiers des panneaux Projects et Storage Manager, par une série d’alertes VCS et par des modifications appropriées des commandes de gestion de fichiers disponibles.

Les icônes et leur signification sont décrites dans la section Version Control Status Icons de la page Managing Project Documents .

Accès multi-utilisateur

Dans la plupart des cas, l’infrastructure de gestion de versions d’une entreprise repose sur des dépôts SVN ou Git centralisés, servis sur le réseau à l’aide de l’une des méthodes de protocole disponibles – svn, svn+ssh, https, etc. Cela fournit un accès à tous les utilisateurs du réseau, sous réserve des autorisations, ainsi qu’un moyen de développement collaboratif des projets à partir d’une source unique.

En retour, les capacités d’accès multiple permettent à différents membres de l’équipe de continuer à travailler sur un projet de manière indépendante, sans avoir à attendre que quelqu’un d’autre réintègre un fichier avant de pouvoir travailler dessus. Un système de gestion de versions Git distribué pousse cet avantage encore plus loin en permettant de valider les fichiers dans le dépôt de travail local au fur et à mesure du travail, puis de « pousser » ces modifications validées vers le dépôt Git central à tout moment ultérieur ; ainsi, aucune connexion réseau n’est requise avant cela.

Néanmoins, un VCS compatible avec le travail en équipe exige que des outils et des techniques soient disponibles pour résoudre la situation inévitable où deux utilisateurs ont modifié le même fichier. Lorsque ces capacités sont disponibles, les bases d’une véritable collaboration de conception multi-utilisateur et de ses avantages associés sont en place.

Pour prendre en charge cette situation, Altium Designer inclut des capacités de comparaison de schémas et de PCB (ou « diff »), disponibles via le panneau Storage Manager.

Dépôts VCS

La meilleure façon de travailler à partir d’un ensemble connu de fichiers source consiste à stocker le projet de conception dans un environnement contrôlé, tel qu’un dépôt de gestion de versions. Cela est important, car la seule manière de garantir que les sorties proviennent des bons fichiers source est de :

1. Confirmer que l’ensemble des fichiers source est à jour.
2. En prendre un instantané.
3. Générer les sorties à partir de cet instantané.

Dans Altium Designer, un tel dépôt est appelé Design Repository. Propriété de l’équipe de conception, le Design Repository offre une vue détaillée de l’historique du processus de conception et constitue l’outil principal de collaboration utilisé par l’équipe de conception.

Le Design Repository devient le dépôt central à partir duquel plusieurs membres de l’équipe peuvent extraire et réintégrer des données, tout en conservant un historique complet des révisions de toutes les modifications apportées à la conception. Une conception est donc stockée sous la forme d’une série de versions de ses documents projet et source constitutifs, construisant au fil du temps une image progressive de l’intention du concepteur. En utilisant un Design Repository sous gestion de versions, vous avez l’assurance intrinsèque qu’aucune révision d’une conception n’est jamais perdue, ce qui permet une collaboration sûre sur une même conception entre des membres d’une équipe pouvant être géographiquement dispersés. La nature même du système de gestion de versions fournit une piste d’audit pour la conception. Une responsabilité complète découle de la transparence sur qui a modifié quoi, dans quel document source et à quel moment. Le système peut prendre en charge plusieurs Design Repositories sous gestion de versions, le lien vers un dépôt particulier étant établi par le lien de gestion de versions dans le dossier du projet.

Avant d’utiliser la gestion de versions, les fichiers du projet doivent être reconnus à la fois par le VCS et par Altium Designer comme étant sous gestion de versions. Ce processus peut différer selon les différentes méthodes et applications VCS, mais il consiste essentiellement à créer et/ou à se connecter à un dépôt de conception et à y ajouter les fichiers du projet de conception.

Les dépôts de conception reposent sur une structure de base de données et stockent en interne les informations dans une hiérarchie de fichiers et de répertoires, appelée arborescence de fichiers. Le dépôt réel auquel vous vous connectez peut être un dépôt SVN central, un dépôt de travail Git (associé à un dépôt Git distant), ou un dépôt que vous avez créé dans un emplacement accessible, par exemple sur le PC local ou dans un emplacement réseau partagé.

Mettre à jour les nouvelles modifications vers le contrôle de version

Lorsqu’un projet a été ajouté au contrôle de version, son dossier de projet de travail local est désormais lié à son équivalent dans le dépôt VCS, comme l’indique l’icône de lien associée aux entrées du dossier de projet dans le panneau Storage Manager. Pour confirmer les emplacements du dossier lié et du dépôt, cliquez avec le bouton droit sur n’importe quelle entrée de fichier dans le panneau et sélectionnez l’option VCS Properties (non disponible lors de l’utilisation de Git). La boîte de dialogue Properties suivante inclut les chemins des emplacements liés et des informations sur la dernière révision VCS.

Fichier indiqué par l’icône de lien et le Properties panneau correspondant contenant des informations sur la dernière révision VCS

La boîte de dialogue Properties fournit les informations suivantes (ces informations sont uniquement destinées à la consultation ; aucune modification n’est autorisée) :

• Path - le chemin vers le document local dans votre dossier de travail).
• URL - l’URL de l’emplacement du document dans le dépôt VCS.
• Repository Root - la racine du dépôt.
• Repository UUID - l’UUID du dépôt.
• Revision - la révision actuelle du document dans votre dossier de travail local.
• Last Change Author - l’auteur de la dernière modification.
• Last Change Revision - la révision de la dernière modification
• Last Change Time - la date et l’heure de la dernière modification.
• Conflicted - si le document est en conflit ou non.

Grâce au lien VCS enregistré, le système de gestion de versions peut surveiller et détecter toute différence entre les fichiers du dossier de projet local et leurs équivalents dans le dossier du dépôt VCS. Lorsqu’une différence est détectée, par exemple lorsqu’un fichier de conception a été modifié et enregistré dans Altium Designer, le système de gestion de versions change l’état du fichier local en Modified () et Altium Designer propose un ensemble approprié de commandes VCS dans le menu contextuel des panneaux.

Valider les modifications

Après qu’un fichier de document de projet a été modifié et enregistré dans Altium Designer, il est marqué comme Modified, et indiqué comme tel () dans les panneaux Projects et Storage Manager. Pour valider ces modifications comme nouvelle révision dans le VCS, cliquez avec le bouton droit sur l’entrée du fichier dans le panneau et sélectionnez la commande Commit dans le menu contextuel, ou sélectionnez la commande Project » History & Version Control » Commit dans les menus principaux.

Lors de la validation d’une modification d’un fichier, la boîte de dialogue Edit Comment dialog s’ouvre. Utilisez cette boîte de dialogue pour ajouter un commentaire indiquant la raison de la validation, ce qui peut aider les autres à voir quelles modifications ont été apportées. Si vous avez ajouté des commentaires précédents, vous pouvez rapidement en sélectionner un pour le réutiliser.

La commande Commit

La commande Commit Whole Project peut également être utilisée ; elle validera tous les fichiers modifiés du projet. Lors de la validation du projet entier, la boîte de dialogue Commit to Version Control s’ouvre.

La boîte de dialogue Commit to Version Control

• When using Subversion (SVN): Le processus de validation copie le fichier mis à jour du dossier local vers le dépôt, incrémente le numéro de révision de l’entrée VCS et remet l’état du fichier à No Modification ().
• When using Git:Le processus de commit met à jour le dépôt de travail local du VCS tout en incrémentant le numéro de révision de l’entrée et en définissant l’état du fichier sur Ahead of Server (). Vous pouvez continuer à modifier, enregistrer et valider les fichiers dans le dépôt de travail local ou ratifier les nouvelles modifications à l’aide de la commande Push pour mettre à jour le dépôt Git distant – l’état du fichier reviendra alors à No Modification ().

Affichez le panneau Storage Manager pour voir la séquence d’actions dans la section VCS Revisions, qui inclura la création d’une nouvelle révision VCS (avec un numéro de révision incrémenté) pour ce fichier – dans ce cas, la révision 3 et le commentaire qui lui a été ajouté. L’icône indique la révision la plus récente et la révision actuelle du fichier sélectionné, ou, dans la terminologie du contrôle de version, la révision Head.

La section VCS Revisions du panneau Storage Manager

Pour une vue combinée des entrées de révision et des événements d’historique, passez à la vue unique Timeline en sélectionnant Switch to Combined View dans le menu contextuel accessible par clic droit.

Extraction depuis le contrôle de version

Comme indiqué ci-dessus, un projet local qui a été ajouté au contrôle de version peut être modifié par Altium Designer depuis le dossier local du projet, puis les modifications sont mises à jour dans le dépôt VCS. Le dossier local et le dossier du dépôt sont liés et finalement synchronisés par le VCS.

Un autre utilisateur, qui n’aura pas accès au projet depuis son dossier source (qui est local à votre PC), peut utiliser le processus Clone (Git) ou Check Out (SVN) pour obtenir sa propre copie des fichiers depuis le dépôt VCS qui héberge le projet. Tous les utilisateurs souhaitant collaborer à la conception du projet devront se connecter à ce dépôt de conception commun, généralement configuré pour être accessible via le réseau local ou depuis un serveur.

Le dossier du projet sélectionné dans le dépôt ainsi que les fichiers qui le composent seront extraits vers le dossier local spécifié et ouverts dans Altium Designer. Notez que le dossier local est celui défini comme dossier d’extraction pour le dépôt sélectionné, et que le projet extrait est ensuite lié à son équivalent dans le dépôt VCS. Le lien VCS indique au système de contrôle de version de surveiller et de détecter toute différence entre les fichiers du dossier local d’extraction et leurs équivalents dans le dossier du dépôt VCS.

Validez les modifications lorsque l’édition des fichiers est terminée, ce qui synchronisera les fichiers du dépôt de conception pour qu’ils correspondent à ceux du dossier d’extraction, en créant une nouvelle révision VCS.

Check Out vs Open Project

Lorsqu’un projet local a été ajouté au contrôle de version, il existe en réalité deux façons de le modifier et de le mettre à jour dans le VCS :

• En ouvrant le projet local (File » Open Project) dans Altium Designer, puis en validant les modifications enregistrées dans le dépôt VCS. Dans ce cas, le dossier du projet local et son équivalent dans le dépôt sont liés par le VCS.

  

• En extrayant le projet (File » Check Out) depuis le dépôt VCS, puis en validant dans le dépôt les modifications enregistrées effectuées dans Altium Designer. Dans ce cas, le projet dans le dossier d’extraction désigné et son équivalent dans le dépôt sont liés par le VCS.

  

Le projet local est la source, ou l’origine, du projet VCS partagé avec d’autres utilisateurs. Selon votre manière de travailler, cette version source locale peut être supprimée ou verrouillée comme source de projet archivée, puis l’approche Check Out peut être utilisée pour effectuer d’autres modifications. Ou bien, vous pouvez continuer à ouvrir et à utiliser les fichiers du projet depuis le dossier « source » local (Open Project).

La meilleure approche consiste à s’en tenir à une seule méthode (l’extraction est recommandée), puisque les deux options traitent un dossier de travail situé à des emplacements différents – le dossier du projet source local, ou le dossier d’extraction VCS désigné. À l’inverse, si les deux méthodes sont utilisées, il y aura plusieurs copies actives du même projet sur le PC local. Si ces versions sont néanmoins systématiquement validées dans le dépôt VCS centralisé après chaque modification, le dépôt contiendra toujours la dernière révision du projet, comme prévu.

Notez également qu’une fois qu’un projet a été extrait initialement du dépôt VCS, il existe alors localement et peut être rouvert directement depuis le dossier d’extraction (File » Open Project). Dans ce cas, il est à nouveau possible soit d’extraire un projet depuis le VCS, soit d’ouvrir la version locale ; toutefois, il n’existe alors qu’une seule copie locale. En termes pratiques de VCS, les deux méthodes sont très similaires mais se comportent différemment dans certaines circonstances – par exemple lorsqu’un fichier local est manquant : il sera restauré par le processus d’extraction, mais il sera supprimé du projet par une commande Open Project.

Révisions du contrôle de version

Au cours du travail avec des documents de conception dans Altium Designer placés sous contrôle de version, les fichiers de conception auxquels on a accédé depuis le dépôt VCS central (partagé) représenteront la dernière révision de ces fichiers. Lorsque les modifications locales sont terminées et ont été validées (ou, avec Git, poussées) vers le dépôt VCS partagé, ces versions de fichiers deviennent alors les dernières révisions.

Ainsi, la séquence normale extraction, modification, enregistrement et validation (et Push, avec Git) ajoute progressivement de nouvelles révisions de fichiers au VCS central à mesure que la conception du projet évolue. Toutefois, lorsqu’un projet est développé en collaboration par plusieurs concepteurs, de nouvelles révisions peuvent être validées dans le dépôt central (partagé) à tout moment, par n’importe quel concepteur.

Révision obsolète

L’interaction entre plusieurs concepteurs et le dépôt central peut se manifester de plusieurs façons, notamment par le fait qu’un projet ouvert localement n’est plus la dernière révision – un projet extrait du dépôt ou ouvert depuis le dossier de travail local a un état Out of date () dans le panneau Projects.

Fichier étiqueté Out of fate

Dans ce cas, un autre utilisateur a modifié et validé le même projet dans le dépôt depuis sa dernière modification locale. Par exemple, un utilisateur local Barry travaille sur le projet et a validé, disons, Revision 14, mais un autre utilisateur Harold a validé Revision 15 après cela, comme indiqué dans le panneau Storage Manager ci-dessous. Comme le VCS détecte la différence entre un fichier dans le dossier de travail local et son équivalent dans le dépôt (qui est plus récent dans ce cas), le système considère la plus récente révision local (indiquée par l’icône ) comme obsolète.

Différents états de révision dans le Storage Manager

Cette situation est corrigée en mettant à jour les fichiers locaux pour qu’ils correspondent à ceux du dépôt VCS central à l’aide de la commande Update depuis le menu contextuel accessible par clic droit du panneau Projects ou Storage Manager. Les deux versions du fichier sont alors synchronisées, la version locale (pour l’utilisateur Barry) étant mise à jour vers la dernière version de révision – dans cet exemple, Revision 15. Notez que si vous Save un fichier alors qu’il est désigné comme Out of date, cela créera une situation de Conflict VCS, dans laquelle le VCS détecte qu’une ancienne révision d’un fichier a été mise à jour dans le dossier de travail.

Le dépôt central et la révision locale dans le Storage Manager

Vous pouvez également sélectionner la commande Update Whole Project pour accéder à la boîte de dialogue Update from Version Control qui vous permet de sélectionner les fichiers à extraire depuis un dépôt partagé. Tous les documents du projet qui sont obsolètes ou contiennent des conflits sont affichés dans la boîte de dialogue. Vous pouvez sélectionner des documents spécifiques à mettre à jour ou choisir de tous les mettre à jour en une seule fois. Les documents sélectionnés sont mis à jour depuis le dépôt et tous les documents obsolètes sont sélectionnés par défaut. Tous les documents sélectionnés seront mis à jour vers la dernière version du dépôt.

La boîte de dialogue Update from Version Control

La colonne Path affiche le répertoire du fichier. La colonne Status affiche l’état actuel du fichier. Si l’état d’un fichier est affiché comme Conflict, cliquer sur OK pour mettre à jour les fichiers fera apparaître une boîte de dialogue de confirmation. Cliquez sur OK pour mettre à jour vers la dernière version du dépôt ou sur Cancel pour quitter et enregistrer les modifications dans la version actuellement présente dans le dépôt.

Conflit de révision

L’interaction entre plusieurs concepteurs et le dépôt central peut également créer une situation où le même fichier a été modifié et enregistré localement par deux utilisateurs d’Altium Designer, et où l’un d’eux a validé ces modifications.

Cela signifie que la séquence d’étapes d’un concepteur (extraire, modifier, enregistrer, valider) s’est entremêlée avec celle d’un autre concepteur, de sorte qu’un fichier qu’un utilisateur a extrait du dépôt pour le modifier peut ne pas remain correspondre à la dernière révision pendant qu’il est en cours de modification – un autre utilisateur a entre-temps mis à jour la révision. Dans ce cas, la première personne qui valide les modifications dans le dépôt l’emportera en créant une nouvelle révision, tandis qu’un autre utilisateur ayant modifié et enregistré le même fichier sera confronté à une situation de Conflict conflit de révision – indiquée par l’icône .

Exemple de conflit de révision

Du point de vue d’un VCS, qui compare les fichiers du dossier de travail aux fichiers du dépôt, un conflit représente la situation dans laquelle une révision obsolète d’un fichier dans le dossier de travail a été modifiée et enregistrée.

Révisions Git VCS dans le panneau Storage Manager

Plusieurs options de commande sont accessibles depuis le menu contextuel par clic droit History & Version Control du panneau Projects, le menu principal Project » History & Version Control et le panneau Storage Manager, et peuvent être utilisées lorsqu’un fichier a l’état Conflict :

• Commit – cette option déclenchera une erreur Subversion, car valider la révision modifiée localement (par exemple, Revision 15) écraserait la révision plus récente (Revision 16) déjà validée par un autre utilisateur.
• Update – cette option mettra à jour la révision du fichier local vers la dernière version du dépôt central (Revision 16), ce qui entraînera la perte de toutes les modifications locales que vous avez apportées à Revision 15.

• Resolve Conflict – cette option ignorera les modifications validées dans le dépôt depuis votre dernière mise à jour. Après le lancement de la commande, une boîte de dialogue de confirmation apparaîtra - cliquez sur Yes pour continuer. Le fichier de projet dans votre dossier de travail sera mis à jour vers la dernière révision enregistrée dans le dépôt par l’autre utilisateur, mais l’éditeur conservera les modifications que vous avez apportées à la révision précédente. Le fichier local acquiert donc un état de Modified, vous permettant de valider ces modifications dans une nouvelle révision du dépôt - à l’aide de la commande Commit, ou de la commande Commit Whole Project. Une fois que vous avez validé le fichier de projet, l’autre utilisateur verra le(s) fichier(s) comme étant Out of date, puisque vous avez créé une révision plus récente dans le dépôt.

  Cette option n’est recommandée que lorsqu’un fichier text est en conflit, car le système Subversion tentera de fusionner les différences dans le fichier local. Ce processus risque de corrompre d’autres types de fichiers, tels que les documents de conception ; il est donc préférable de résoudre un conflit en mettant à jour vers la dernière révision source ou en annulant les modifications locales.

  Lors de l’utilisation de Git, la commande Resolve Conflict remplacera la condition de conflit en validant le fichier dans le dossier du dépôt local. Lorsque le fichier est ensuite poussé vers le dépôt distant, le fichier de l’autre concepteur sera marqué comme Out of Date et devra être mis à jour. Comme avec Subversion, toutefois, la voie la plus sûre consiste à Update mettre à jour le fichier en conflit vers la dernière révision source (un Pull dans la terminologie Git) ou à Revert annuler les modifications locales.
• Revert – cette option entraînera la perte (annulation) des modifications locales, en rétablissant le fichier local à sa révision de base – ici, Revision 15. Le conflit de révision est ainsi résolu, mais le fichier sera alors marqué comme Out of date puisqu’une révision plus récente (Revision 16) existe dans le dépôt.

Comparer les révisions

Un avantage précieux du travail avec le contrôle de version est la possibilité de comparer les révisions historiques des fichiers de conception, fournie par le comparateur de différences intégré d’Altium Designer et accessible depuis le panneau Storage Manager. Lorsqu’il est utilisé conjointement avec le panneau Differences, une comparaison logique ou graphique peut être effectuée entre les révisions VCS tout en explorant de manière interactive les objets concernés. Les révisions de schémas et de PCB peuvent toutes deux être comparées.

Pour lancer une comparaison entre deux révisions, sélectionnez les deux entrées (en utilisant la méthode standard Ctrl+click) dans la liste VCS Revisions du panneau Storage Manager, puis sélectionnez la commande Compare dans le menu contextuel par clic droit du panneau.

La commande Compare dans le panneau Storage Manager

Les deux révisions du fichier seront ouvertes en mode écran partagé, où elles pourront être comparées visuellement. Les différences affichées sont déterminées par les options sélectionnées pour les types de comparaison physique dans l’onglet Comparator tab de la boîte de dialogue Options for Project – Project » Project Options.

La clé pour localiser et visualiser les différences de comparaison se trouve dans le panneau Differences, qui fournit une liste sélectionnable des différences logiques ou graphiques entre les documents. Les entrées listées dans le panneau pour chaque révision de document interagissent avec l’éditeur, ce qui permet de mettre graphiquement en évidence une différence détectée (comme un objet déplacé) lorsqu’elle est sélectionnée.

La localisation et la visualisation des différences de comparaison se font dans le panneau Differences

La fonctionnalité de comparaison s’applique également aux révisions des documents PCB, ainsi qu’aux révisions des schémas et des documents textuels.

• Pour les documents schématiques ou PCB (conception ou bibliothèque), une comparaison graphique est effectuée et les différences détectées sont listées dans le panneau Differences. Avec les deux versions du document ouvertes côte à côte dans la fenêtre de l’éditeur de conception, vous pouvez parcourir graphiquement les différences. En cliquant sur un dossier de niveau supérieur correspondant à une différence détectée, cette différence sera mise en évidence simultanément dans les deux documents.
• Pour les documents ASCII textuels, la boîte de dialogue CompareForm apparaîtra, affichant un « diff » graphique des deux versions du document. Les documents choisis sont affichés côte à côte. La boîte de dialogue est uniquement destinée à la comparaison - aucune modification d’un document chargé ne peut être effectuée. Grâce à un code couleur, la boîte de dialogue met en évidence les différentes différences entre les deux versions du document - lignes ajoutées (rose), lignes modifiées (vert) et lignes supprimées (bleu). Un résumé des modifications et une légende du code couleur sont présentés en bas à gauche de la boîte de dialogue.

La fonctionnalité de comparaison

La commande Compare peut être appliquée à n’importe quelle paire de révisions, y compris entre la révision locale actuelle (dans le dossier de travail) et une révision plus récente dans le dépôt. Dans cette situation, la dernière révision locale est indiquée dans le panneau Storage Manager comme Out of date () mais peut néanmoins être comparée à une révision plus récente qui a été ajoutée au dépôt par un autre utilisateur.

La révision locale est indiquée dans le panneau Storage Manager comme obsolète

Cette approche vous permet de prévisualiser graphiquement les modifications qui seront imposées par la mise à jour vers la nouvelle révision. Dans l’exemple illustré ci-dessus, la révision locale actuelle (indiquée par l’icône ) est Revision 19, mais un autre utilisateur a validé une nouvelle révision dans le dépôt (Revision 22). Lancer une comparaison visuelle entre Revision 19 et Revision 22 vous permet de prendre une décision éclairée quant à l’acceptation des nouvelles modifications provenant du dépôt, et par implication, de déterminer si vous appliquerez la commande Update ou si vous passerez outre en provoquant une condition de conflit – en réenregistrant le fichier local et en résolvant le conflit en faveur de votre version locale.

Terminologie du contrôle de version

Références

• Site web SVN : http://subversion.apache.org/
• Manuel SVN en ligne : http://svnbook.red-bean.com/
• Page d’accueil du projet SharpSVN : https://sharpsvn.open.collab.net
• Site web Git : https://git-scm.com/
• Documentation Git en ligne : https://git-scm.com/doc
• Les clients Tortoise : http://tortoisesvn.net et https://tortoisegit.org/
• Guide pratique du contrôle de source, par Eric Sink : http://www.ericsink.com/scm/source_control.html