View Issue Details

IDProjectCategoryView StatusLast Update
0001818Common[All Projects] Generalpublic2016-11-06 23:49
ReporterXenosAssigned ToXenos 
PrioritynormalSeverityfeatureReproducibilityN/A
Status CloseResolutionfixed 
Product Version1.0.4 
Target VersionFixed in Version3.0.0 
Summary0001818: Versionner les tags des dépôts Mercurial
DescriptionActuellement, j'utilise les "localtags" pour indiquer les numéros de version des commits déployés, ainsi que le nom de l'environnement mage où il a été déployé, et le dernier commit dont les n° de tickets ont été traités.

Par exemple, pour "Common", j'ai les version 2.0.12 pour le commit a28957b941a2, la version 2.0.14 pour le commit a2cccfc9d8bf et la version 2.0.15 pour le commit 042abaa45777. De cette façon, je peux revenir à une version antérieure précise si nécessaire (en cas de bogue non reproductible par exemple).

Egalement, j'ai le tag "common-prod" sur le commit 042abaa45777 car c'est le commit actuellement déployé chez OVH pour l'environnement Mage "common-prod". Je n'ai généralement qu'un environnement mage par projet, mais je pourrai en avoir plusieurs (chacun aurait alors son propre tag).

Enfin, le commit 042abaa45777 possède le tag "mantis", qui indique que tous les commits précédents ont été analysés pour en récupérer les numéros de ticket, et que Mantis a été mis à jour pour indiquer les versions de résolution de chacun de ces tickets (c'est automatique: quand je déploie, les tickets déployés sont passés "released on prod" et le numéro de version de leur résolution est mis à jour).

Donc, ces tags sont tous locaux (car faire des tags non-locaux obligerait à faire 1 commit par tag, ce qui va inutilement polluer le dépôt).

Ce qui fait que si je clône le dépôt, alors je perds les tags: si jamais mon ordi tombe en rade et que je récupère les clones de mes backups, alors j'aurai perdu TOUS ces tags locaux.

Pour éviter cela, je vais versionner les fichiers contenant les tags locaux. Ces fichiers seront tous versionnés dans le projet "Common". De cette façon, je pourrai les récupérer si nécessaire.

En revanche, cela implique que, quand je déploie un projet, ces fichiers dans "Common" seront modifiés et mis à jour. Commiter ces fichiers ne se fera pas dans un commit séparé: si je modifie des trucs dans "Common" (par exemple, le framework PHP) et que des fichiers de tags ont été modifiés, alors je les commiterait en même temps que mes modifications normales. J'aurai donc un commit avec mes modifications de framework PHP mais également avec les modifications des fichiers de tag.

On verra à l'usage si c'est pratique, mais cela me semble indispensable car si je ne les versionne pas, je suis dans la merde. De plus, impossible de les versionner chacun dans leur projet: si je versionne le fichier "localtag" d'ECLERD dans le projet ECLERD, alors à chaque déploiement, le fichier sera modifié (des tags auront été ajoutés) et du coup, je ne pourrai pas facilement redéployer ce projet (ie: si le déploiement échoue, le tag "vx.y.z" aura été ajouté, donc le dépôt aura été modifié, donc je ne pourrai pas relancer le déploiement sans devoir aller revert ces modifications).
TagsNo tags attached.
Attach Tags

Activities

Xenos

Xenos

2016-10-18 22:47

administrator   ~0002665

Je verrai à l'usage, mais cela me semble être une bonne approche.

Les fichiers de tags sont nommés ".../.hg/localtags". Le projet "Common" utilise des hardlinks vers ces fichiers (de Common vers ".../.hg/localtgs") pour en assurer la synchronisation.

Si je veux clôner le dépot, j'aurai donc juste à faire un hardlink de ".../.hg/localtags" vers le projet Common (dans l'autre sens donc).
Xenos

Xenos

2016-10-21 00:39

administrator   ~0002670

Last edited: 2016-11-06 23:49

En fait, il ne faut pas un hardlink, mais un symlink!

En effet, le fichier "localtags" est supprimé à chaque changement de tags par Mercurial, donc un hardlink sera rompu.
Un symlink n'aura pas ce problème, car si le fichier cible est supprimé puis recréé par Mercurial, alors le symlink pointera toujours dessu (alors qu'un hardlink sera "détaché" de sa copie originelle).
Xenos

Xenos

2016-10-24 16:36

administrator   ~0002688

Last edited: 2016-11-06 23:49

Bon, je ne crois pas que cela marche en fait, vu que j'ai déployé des trucs sans être obligé de les commiter dans le projet "Common" (ce qui tendrait à prouver que le versionning de ces liens symboliques ne se fait pas).

Je pourrai toujours essayer une "copie intelligente", mais bon... Comme ce n'est pas dramatique, je vais laisser cela comme c'est (je n'ai pas de raison d'avoir besoin des vieilles versions d'un projet, et j'ai une bonne partie des numéros de version dans Mantis même, donc je pourrai m'en sortir si besoin).

Issue History

Date Modified Username Field Change
2016-10-18 22:45 Xenos New Issue
2016-10-18 22:45 Xenos Status New => Accepted
2016-10-18 22:47 Xenos Note Added: 0002665
2016-10-18 22:47 Xenos Status Accepted => Ready
2016-10-18 22:47 Xenos Resolution open => fixed
2016-10-18 22:47 Xenos Assigned To => Xenos
2016-10-21 00:39 Xenos Note Added: 0002670
2016-10-24 16:35 AutoUpdater Status Ready => Resolved
2016-10-24 16:35 AutoUpdater Fixed in Version => 2.1.0
2016-10-24 16:36 Xenos Note Added: 0002688
2016-10-24 16:36 Xenos Status Resolved => Close
2016-11-06 23:49 AutoUpdater Fixed in Version 2.1.0 => 3.0.0