Stockage basé sur des fichiers
Dans CODESYS 3 Un projet est stocké dans un unique fichier binaire. Le contenu de ce fichier ne peut être ni lu ni modifié en dehors de l'environnement de développement. La comparaison de deux versions d'un même projet ne révèle aucune différence notable, et deux éditeurs entrent déjà en conflit lorsqu'ils modifient des objets différents.
Après avoir installé le CODESYS File-Based Storage module complémentaire dans CODESYS 3, un format de stockage basé sur des fichiers est fourni, compatible avec le format de stockage de CODESYS 4 Il permet la conversion du format basé sur des fichiers en CODESYS 4 au format binaire dans CODESYS 3 et retour.
Dans CODESYS 4 Dans ce projet, la gestion s'effectue selon un format ouvert basé sur les fichiers. Chaque objet est stocké dans son propre fichier texte, et la structure du projet correspond à l'arborescence des dossiers du système de fichiers. Il n'existe pas de gestionnaire d'objets.
Il en résulte les avantages suivants.
Un objet peut être lu avec n'importe quel éditeur de texte et modifié si nécessaire.
La comparaison de deux états de projet montre les modifications de contenu en texte brut.
Les modifications apportées à différents objets ne sont pas conflictuelles entre elles.
Un projet est géré dans un système de contrôle de version tel que Git, SVN ou Mercurial. L'archive du projet provient de CODESYS 3 est inutile à cause de cela.
Les processus habituels d'un système de contrôle de version – tels que les demandes de fusion, les demandes d'extraction et les revues de code – peuvent être utilisés car les modifications peuvent également être visualisées sur le portail web du système de contrôle de version.
Pour plus d'informations, consultez les documents suivants : Espaces de travail et types de fichiers
Code source et fichiers générés
Tout ce qui se trouve dans le dossier du projet n'appartient pas au texte source. Outre les fichiers objets, CODESYS 4 Il stocke également les résultats temporaires, les bibliothèques résolues et les paramètres spécifiques à l'utilisateur. Ces fichiers sont régénérés en fonction des besoins.
Dossier | Emplacement | Contenu |
|---|---|---|
| Dans le | Contextes de compilation et de référence |
| Dans le | Fichiers temporaires créés à des fins de diagnostic |
| Dans le | Application de démarrage hors ligne générée si aucun chemin n'est spécifié |
| Niveau supérieur en | Bibliothèques compilées résolues |
| Niveau supérieur du projet | Paramètres du projet et préférences de l'utilisateur Le répertoire est créé uniquement lors de la première sauvegarde d'un paramètre de projet personnalisé. |
| Parallèlement au fichier d'espace de travail | Paramètres de l'espace de travail et préférences utilisateur |
Le cache des descriptions de périphériques, quant à lui, appartient au projet. Ces descriptions sont disponibles sous forme de fichiers texte et font l'objet d'un système de contrôle de version.
Jeu de caractères, sauts de ligne et indentation
Pour garantir qu'une comparaison entre deux versions d'un projet révèle des modifications de contenu et non des modifications de format, tous les fichiers sont écrits selon des règles fixes. CODESYS 4.
Propriété | Règle |
|---|---|
Jeu de caractères pour le code source IEC et les fichiers JSON | UTF-8 sans BOM (Marqueur d'ordre d'octet ) Les fichiers omettent initialement toute information concernant l'encodage des caractères utilisé. |
Jeu de caractères pour les fichiers XML | UTF-8 préféré Les fichiers d'inventaire, tels que les descriptions des appareils, sont lus en fonction de leur déclaration de métadonnées. |
Saut de ligne pendant l'écriture | LF (Alimentation de ligne ) |
Saut de ligne pendant la lecture | LF et CRLF (Ligne de retour chariot ) |
Indentation dans les fichiers JSON et XML | 1 onglet par niveau |
Ordre des entrées dans les objets JSON | Déterministe |
Les fichiers sont toujours enregistrés au format de fin de ligne LF (0x0A). LF et CRLF (0x0D, 0x0A ) sont pris en charge lors de l'importation. Cela garantit que les fichiers restent lisibles même s'ils ont été modifiés en dehors de CODESYS 4 avec un éditeur qui utilise le format de fin de ligne CRLF.
Projets dans les systèmes de contrôle de version
L'ordre déterministe des objets JSON et l'indentation par tabulation ont le même but : un objet modifié ne crée une différence que là où son contenu a changé.
fichiers objets
fichiers de configuration du projet tels que
Libraries.jsonetProjectInfo.jsonLibraries.lock.jsonfichier de verrouillageFichier d'espace de travail
Les dossiers et fichiers générés à partir du code source ne font pas partie du contrôle de version. Ils contiennent des données temporaires, des fichiers binaires ou des paramètres spécifiques à l'utilisateur. D'autres environnements de développement gèrent cela de la même manière ; par exemple, un projet C# possède… bin et obj dossiers.
Pour les dossiers suivants, l'exclusion est activée par défaut et non obligatoire. Si les fichiers binaires ne posent pas de problème à votre système de gestion de versions, vous pouvez alors inclure ces dossiers.
Fichiers exclus du contrôle de version :
.library-cache.user<workspace name>.fbsws.user
Configurez le système de contrôle de version afin que les fichiers soient convertis au format LF (Alimentation de ligne ) lors de l'enregistrement, et récupéré sans modification lors de l'extraction. Dans Git, vous pouvez configurer cela avec les paramètres suivants.
core.eol = lf core.autocrlf = false
Enregistrez les exclusions pour chaque dossier de projet dans un fichier séparé. .gitignore l'extension, et les paramètres de sauts de ligne dans un fichier séparé avec le .gitattributes extension. Les deux fichiers doivent être versionnés, sinon les règles ne fonctionneront pas.
Modifier des fichiers en dehors de CODESYS 4
Les fichiers objets d'un projet sont en texte brut. Si nécessaire, vous pouvez les modifier en dehors de l'environnement de développement. CODESYS 4, par exemple lors de la résolution d'un conflit de fusion ou lors de la réalisation d'une modification qui affecte de nombreux objets de la même manière.
Vous devez ici respecter les conditions suivantes :
La déclaration reste syntaxiquement valide. Elle sert à la distinguer de l'implémentation.
Le jeu de caractères reste UTF-8 sans BOM.
La structure des dossiers reste inchangée car il s'agit de la structure du projet.
Chaque fois que vous résolvez un conflit de fusion en dehors de CODESYS 4, vous devriez vérifier le résultat par la suite dans le CODESYS 4 IDE. Une fusion peut créer des relations entre des objets qui ne sont pas autorisées dans un projet. Par exemple, un POU subordonné à un autre POU.
Les fichiers du système de contrôle de version tels que .gitignore se trouvent dans le dossier du projet et apparaissent donc également dans le navigateur d'espace de travail.