Différences

Ci-dessous, les différences entre deux révisions de la page.

--- electronique:do-254_subversion [2020/01/20 23:50] – créée Pascal Delrot
+++ electronique:do-254_subversion [2020/01/21 00:38] (Version actuelle) – [Sites à consulter pour davantage de précisions] Tri dans les URI Pascal Delrot
@@ Ligne 55: / Ligne 55: @@
 ====Gestionnaires de versions sans concurrence====
-Des logiciels comme Word (il semble que cette fonction ai été supprimée dans Office 2010) ou OpenOffice.org/LibreOffice.org intègrent aussi des gestionnaires de version. Il est possible de les tester en réalisant les manipulations suivantes :
+Des logiciels comme Word ((il semble que cette fonction ai été supprimée dans Office 2010, à date de rédaction en 2020, Office 365 semble posséder quelques options sur ce sujet)) ou OpenOffice.org/LibreOffice.org intègrent aussi des gestionnaires de version. Il est possible de les tester en réalisant les manipulations suivantes :
     * Créer un document et l'enregistrer.
     * Dans le menu Fichier/Versions enregistrer une nouvelle version
@@ Ligne 62: / Ligne 62: @@
 Ils permettent aussi de suivre les modifications apportées à un document en cours d'édition, et de fusionner des documents.
+==== Entre deux gués... ====
+Microsoft Sharepoint permet dans une certaine mesure la modification simultanée par plusieurs utilisateurs, et un contrôle d'accès. Owncloud/Nextcloud sont assez similaires.
+Par rapport à un gestionnaire de versions, la différence majeure est que ces systèmes peuvent **oublier** les anciennes versions.
+  * Sharepoint dans sa version de 2012 environ :
+Les contrôles d'accès étaient précis, à la manière de l'explorateur de fichiers : gestion par utilisateur, par groupes et par fichier et répertoire. L'interface était un peu lourde.
+La modification simultanée par plusieurs utilisateurs était possible, il fallait alors gérer les écrasements et les conflits sur les fichiers.
+  * Sharepoint depuis sa version de 2015 environ :
+le contrôle d'accès a été très simplifié, il apparaît très compliqué de gérer des accès différents d'un répertoire à un autre pour un grand nombre d'utilisateurs (exemple accès interdit à "brouillon" et autorisé en lecture seule au répertoire "en production". D'autre part de mon expérience il est très difficile de supprimer l'accès octroyé à un fichier.
+Le seul moyen de contourner cela est de travailler sur des espaces Sharepoint différents, ce qui implique une duplication du volumes de données, et quelqu'un pour réaliser les copies...
+Les modifications sont tracées, il est possible de suivre les différentes versions d'un fichier. Cette fonction a cependant une limite, dès que le fichier est supprimé suffisamment de temps, tout l'historique est perdu. L'édition simultanée des fichiers en mode collaboratif peut être appréciable.
 ====Gestionnaires de versions avec concurrence====
@@ Ligne 132: / Ligne 147: @@
 On suppose que le projet en question contient 3 modules, 1 cahier des charges, 1 revue de validation.
-On suppose que lors de l'utilisation des opérations suivantes add, commit, copy, les utilisateurs en question indiquent à SVN la raison des opérations effectuées.
+On suppose que lors de l'utilisation des opérations suivantes ''add'', ''commit'', ''copy'', les utilisateurs en question indiquent à SVN la raison des opérations effectuées.
-    -* 1) Création d'un référentiel « PROJETS » par l'administrateur et de droits d'accès types :
+  * 1) Création d'un référentiel « PROJETS » par l'administrateur et de droits d'accès types :
-        -** répertoire « */encours » en lecture/écriture pour l'équipe de développement
+    * répertoire « */encours » en lecture/écriture pour l'équipe de développement
-        -** répertoire « */à valider » en lecture/écriture pour l'équipe de développement
+    * répertoire « */à valider » en lecture/écriture pour l'équipe de développement
-        -** répertoire « */Validé » en lecture/écriture uniquement pour le chef de projet
+    * répertoire « */Validé » en lecture/écriture uniquement pour le chef de projet
-        -** répertoire « */Production » en lecture seule pour la production, et en lecture/écriture pour le chef de projet
+    * répertoire « */Production » en lecture seule pour la production, et en lecture/écriture pour le chef de projet
 Configuration du référentiel : voir la rubrique « administration »
--* 2) Chef de projet (CP) crée un répertoire « PROJET1 » sur son disque local, tel qu'indiqué (droits d'accès entre parenthèses, qui sont prédéterminés dans le serveur) :
+  * 2) Chef de projet (CP) crée un répertoire « PROJET1 » sur son disque local, tel qu'indiqué (droits d'accès entre parenthèses, qui sont prédéterminés dans le serveur) :
-    -** PROJET1/
+    * PROJET1/
-        -*** encours/
+      * encours/
-        -*** à valider/
+      * à valider/
-        -*** Validé/
+      * Validé/
-        -*** Production/
+      * Production/
+  * 3) Le chef de projet « importe » ce répertoire dans le référentiel. Le référentiel est désormais à l'indice 1.
+  * 4) Le cahier des charges est placé par le chef de projet dans le référentiel et le répertoire « Validé ».
-    -* 3) Le chef de projet « importe » ce répertoire dans le référentiel. Le référentiel est désormais à l'indice 1.
+Pour cela il doit d'abord créer une copie locale du référentiel (''checkout''), y placer son cahier des charges, ajouter ce fichier au contrôle de version (''add'') et ensuite valider le document (''commit'') ((Si c'est le répertoire « Validé » qui est validé en entier, il n'est pas nécessaire d'utiliser la fonction « add » pour chaque fichier, la fonction « commit »  du répertoire dans son ensemble suffit.)). Version référentiel = 2
-    -* 4) Le cahier des charges est placé par le chef de projet dans le référentiel et le répertoire « Validé ».
-    Pour cela il doit d'abord créer une copie locale du référentiel (checkout), y placer son cahier des charges, ajouter ce fichier au contrôle de version (add) et ensuite valider le document (commit) [[Si c'est le répertoire « Validé » qui est validé en entier, il n'est pas nécessaire d'utiliser la fonction « add » pour chaque fichier, la fonction « commit »  du répertoire dans son ensemble suffit.]]. Version référentiel = 2
+  * 5) Le développeur 1 (DEV1) crée une copie contrôlée du dossier « PROJET1 » sur son disque (''checkout'').
+  * 6) Il crée le module 1 du projet dans « encours », et l'ajoute au gestionnaire de version (''add'').
-    -* 5) Le développeur 1 (DEV1) crée une copie contrôlée du dossier « PROJET1 » sur son disque (checkout).
+  * 7) Il valide ensuite son module (''commit''). Référentiel indice 3.
-    -* 6) Il crée le module 1 du projet dans « encours », et l'ajoute au gestionnaire de version (add).
+  * 8) Le développeur 2 (DEV2) crée aussi une copie contrôlée du dossier « PROJET1 » sur son disque.
-    -* 7) Il valide ensuite son module (commit). Référentiel indice 3.
+  * 9) Il crée le module 2 du projet dans « encours », et l'ajoute au gestionnaire de version (''add'').
-    -* 8) Le développeur 2 (DEV2) crée aussi une copie contrôlée du dossier « PROJET1 » sur son disque.
+  * 10) Le développeur 1 ajoute un 3ème module (''add'', et ''commit''). Référentiel indice 4.
-    -* 9) Il crée le module 2 du projet dans « encours », et l'ajoute au gestionnaire de version (add).
+  * 11) Le développeur 2 met à jour sa copie locale (''update'')
-    -* 10) Le développeur 1 ajoute un 3ème module (add, et commit). Référentiel indice 4.
+  * 12) Le développeur 2 vérifie son travail et ajoute le 2nd module (''commit'')
-    -* 11) Le développeur 2 met à jour sa copie locale (update)
+  * 13) Le travail est alors considéré prêt à être validé. Le développeur 1 en place une copie dans le répertoire "PROJET1\à valider" du référentiel,
-    -* 12) Le développeur 2 vérifie son travail et ajoute le 2nd module (commit)
+  * 14) Le projet est validé par une réunion. Le chef de projet récupère donc une copie locale des éléments du projet : code source des modules, cahier des charges, et compte rendu de validation. Ces éléments sont placés dans un nouveau répertoire du référentiel "PROJET1\validé\PROJET1 version 1\",
-    -* 13) Le travail est alors considéré prêt à être validé. Le développeur 1 en place une copie dans le répertoire "PROJET1\à valider" du référentiel,
+  * 15) Le projet 1 en version 1 est mis en production. Le chef de projet créé donc une copie du projet 1 version 1 dans le répertoire "production" du référentiel.
-    -* 14) Le projet est validé par une réunion. Le chef de projet récupère donc une copie locale des éléments du projet : code source des modules, cahier des charges, et compte rendu de validation. Ces éléments sont placés dans un nouveau répertoire du référentiel "PROJET1\validé\PROJET1 version 1\",
-    -* 15) Le projet 1 en version 1 est mis en production. Le chef de projet créé donc une copie du projet 1 version 1 dans le répertoire "production" du référentiel.
 ====Questions tests====
@@ Ligne 172: / Ligne 186: @@
 Quel est l'indice du référentiel suite à l'étape 14) ?
 ====Remarque====
@@ Ligne 184: / Ligne 197: @@
 (M) indique dans le tableau ci-dessous les opérations manuelles.
-(A) indiqueles opérations automatisées.
+(A) indique les opérations automatisées.
-|| Exigences DO178B/DO254 et fonctions SVN | Table résumant les avantages de SVN par rapport aux éxigences DO178B/DO254||
+**Exigences DO178B/DO254 et fonctions SVN, table résumant les avantages de SVN par rapport aux exigences DO178B/DO254**
-| ====DO178B==== | ====DO254==== | ====Objectif du processus de gestion de configuration matériel ou logiciel==== | ====C1==== | ====C2==== | ====Gestion via système de fichier classique==== | ====Gestion via SVN==== |
-| X | X | Identification de configuration | X | X | (M) Listing du contenu des versions validées
+^ DO178B ^ DO254 ^ Objectif du processus de gestion de configuration matériel ou logiciel ^ C1 ^ C2 ^ Gestion via système de fichier classique ^ Gestion via SVN ^
- | (A) Listing d’une révision du référentiel |
+| X | X | Identification de configuration | X | X | (M) Listing du contenu des versions validées | (A) Listing d’une révision du référentiel |
 | X | X | Spécifications | X |  | (M) Enregistrement manuel de toutes les révisions | Document intégré au référentiel / Meta-tags |
 | X | X | Traçabilité | X | X | (M) Enregistrement manuel de toutes les révisions | Document intégré au référentiel / Meta-tags |
@@ Ligne 203: / Ligne 216: @@
 | X | X | Restauration | X | X | (M) Sauvegarde sur un autre support | (A) Export / Checkout |
 | X | X | Conservation des données | X | X | (M) Sauvegarde sur un autre support | Sauvegarde référentiel / Export |
-| X | X | Protection contre les modifications non autorisées | X | X | (M) Protéger en écriture les versions validées | Droits d'accès / Annulation des operations non autorisées |
+| X | X | Protection contre les modifications non autorisées | X | X | (M) Protéger en écriture les versions validées | Droits d'accès / Annulation des opérations non autorisées |
-| X | X | Choix des supports, rafraichissement, copie | X |  | Assurance qualité |
+| X | X | Choix des supports, rafraîchissement, copie | X |  | Assurance qualité | Sauvegarde référentiel / Export |
-Sauvegarde référentiel / Export |
 Les avantages de SVN pour une gestion en DO254 HC2 : suivi des documents tels que les cahiers des charges, et le suivi des modification automatique. Il y a en plus un aspect sécurité, car toute action peut être retracée, alors qu'un effacement d'un fichier sur un système de fichier classique peut s’avérer catastrophique.
-En HC1, les gains sont encore supérieurs à cause des changements « incrémentiels » qui allourdissent encore le process de gestion suivi et validation des modifications.
+En HC1, les gains sont encore supérieurs à cause des changements « incrémentiels » qui alourdissent encore le process de gestion suivi et validation des modifications.
 =====Administration d’un référentiel=====
@@ Ligne 216: / Ligne 228: @@
 ====Configuration des droits d’accès :====
-    -* Edition dans un éditeur de texte des fichiers suivants dans le sous-répertoire « \conf\ » du répertoire du référentiel :
+Édition dans un éditeur de texte des fichiers suivants dans le sous-répertoire « \conf\ » du répertoire du référentiel :
-        -** svnserve.conf : configuration du dépot
+        * ''svnserve.conf'' : configuration du dépôt
-        -** passwd : utilisateurs et mots de passe
+        * ''passwd'' : utilisateurs et mots de passe
-        -** authz : droits d’accès par répertoire
+        * ''authz'' : droits d’accès par répertoire
-    Ces fichiers sont commentés, et leur édition ne pose pas de problème particulier.
+Ces fichiers sont commentés, et leur édition ne pose pas de problème particulier.
 ====Sauvegarde :====
@@ Ligne 230: / Ligne 242: @@
   * Les fichiers « log » : Ils peuvent être retirés lorsqu’ils ne sont pas utilisés. Voici la commande pour obtenir la liste des « logs » non utilisés :
     ''svnadmin list-unused-dblogs /référentiel''
-    La commande ''svnadmin hotcopy'' réalise une copie à l’identique du référentiel, en supprimant tous les fichiers « logs ».
+La commande ''svnadmin hotcopy'' réalise une copie à l’identique du référentiel, en supprimant tous les fichiers « logs ».
   * Suppression de ressources :
-    Tel que le site SVN l’indique, la suppression est possible MAIS, tel qu’indiqué par ses concepteurs : <quote> SVN est délibérément conçu pour ne jamais perdre d’information. Les révisions sont des arbres immuables, greffés les uns sur les autres. Retirer une révision pourrait causer un effet « domino », résultant en un chaos dans tous les révisions qui lui sont consécutives, et pouvant donc invalider toutes les copies de travail </quote>
+Tel que le site SVN l’indique, la suppression est possible MAIS, tel qu’indiqué par ses concepteurs :
-    Si toutes les précédentes révisions d’un référentiel (dans son ensemble) sont inutiles, il est donc conseillé d’exporter le référentiel, de le supprimer du serveur, et d’en recréer un à partir de la sauvegarde.
+> SVN est délibérément conçu pour ne jamais perdre d’information. Les révisions sont des arbres immuables, greffés les uns sur les autres. Retirer une révision pourrait causer un effet « domino », résultant en un chaos dans tous les révisions qui lui sont consécutives, et pouvant donc invalider toutes les copies de travail.
+Si toutes les précédentes révisions d’un référentiel (dans son ensemble) sont inutiles, il est donc conseillé d’exporter le référentiel, de le supprimer du serveur, et d’en recréer un à partir de la sauvegarde.
 =====Sites à consulter pour davantage de précisions=====
 Des sites officiels :
-    * http://subversion.tigris.org/
+    * [[https://subversion.tigris.org/|Site officiel de Subversion]]
-    * http://tortoisesvn.net/docs/release/TortoiseSVN_fr/
+    * [[http://tortoisesvn.net/docs/release/TortoiseSVN_fr/|Documentation de subversion en français]]
-    * http://subversionnotify.com/  Cet outil, libre, vous permettra de configurer facilement alertes par emails et conditions de validation des changements dans l'environnement MS Windows (car effet sous système Unix cela ne pause aucune difficulté)
-    * http://www.do254.com/
-    * http://www.do178.net/
 Des sites parlant des thèmes abordés :
-    * http://fr.wikipedia.org/wiki/DO-178B
+    * [[https://fr.wikipedia.org/wiki/DO-178|DO-178 sur Wikipedia]]
-    * http://fr.wikipedia.org/wiki/Subversion_(logiciel)
+    * [[https://fr.wikipedia.org/wiki/Apache_Subversion|Subversion sur Wikipedia]]
-    * http://www.toutprogrammer.com/wiki/Installation_et_utilisation_de_base_de_Subversion
-    * http://www.grappa.univ-lille3.fr/~tommasi/Homepage/SurGestionnaireDeVersions.html
-    * http://www.simpleentrepreneur.com/2009/03/18/les-operations-de-base-dans-subversion/