Convention de nommage SVN: dépôt, branches, tags

j'utilise la tronc, étiquettes, modèle de branches.

Tronc: doit toujours être dans une forme stable. (pas nécessairement diffusable mais stable comme dans aucune erreur de compilateur) je fais généralement des modifications mineures et de nouvelles fonctionnalités qui sont petites et peuvent être complétées en moins d'un jour. Si je développe quelque chose qui prend plusieurs jours et que checkins laisse le tronc dans un état instable, je crée une branche.

branches: sont pour la fonctionnalité développement qui peut laisser le tronc dans un état instable. Il est également utilisé pour "tester" de nouvelles fonctionnalités et des idées. Je m'assure de faire une fusion de mise à jour de tronc à branche pour garder les derniers développements dans le tronc en synchronisation avec ma branche.

tags: sont pour les versions du code que je voudrais retrouver rapidement. En général, je les utilise pour une version particulière (1.00) d'un module ou d'une application. J'essaie de ne pas faire de check-in sur les étiquettes. Si il y a des bugs, ces modifications sont faites dans le coffre et qu'il sera là pour la prochaine version. Les seules exceptions que je fais sont pour les bogues d'urgence. Cela implique qu'une étiquette aura été correctement QA'D et est assez stable.

camelCase? Non, nous ne mettons pas de restrictions sur les noms, sauf que les espaces ont tendance à être découragés. C'est le contenu qui importe, pas la présentation. Tant que le nom est clairement défini ce qu'il fait, nous en sommes heureux.

je pense que le plus grand changement que vous pouvez faire est de mettre tous vos projets dans un seul repo au niveau supérieur.

nous n'utilisons pas de répertoires de branches ou de tags car nous avons plusieurs centaines de projets, chacun divisé en groupes suivis en versions (c'est-à-dire que nous avons une base plate-forme qui est versioned, et beaucoup de plugins qui vivent sous chaque numéro de version de base)

par exemple:

base v1
  +--- moduleA
  +----moduleB
base v2
  +--- moduleA
  +----moduleB

nous avons pensé à placer une branche de balise sous chacun des répertoires du module, mais nous traitons presque toujours de la version head, donc ce n'est pas un problème pour nous. Nous fusionnons régulièrement les changements des anciens modules de version de base à la nouvelle-par exemple faire un changement à moduleA pour la base v1, les changements sont fusionnés dans la base v2 moduleA. Nous ne reculons pas à moins que nécessaire.

chaque module a une note de version avec elle, qui décrit le numéro de version et les changements. Le Commentaire du journal contient une partie de la description et du numéro de version. Cela rend très facile d'obtenir des versions précédentes sans avoir à avoir beaucoup de branches d'étiquette qui sont nommées de façon unique. Si nous avons commencé à utiliser des branches de balise (cela a été suggéré) alors nous avons fait une copie complète du chemin dans le répertoire /tags), Nous avons tout de même fusionné sur une seule branche de balise et mis un commentaire de journal en marquant le numéro de version, nous avons juste trop de modules pour les gérer comme un dossier de balise par branche. Et non, nous ne modifions jamais les révisions historiques - si un client a besoin de nouvelles fonctionnalités, il doit passer à la dernière version (ce qui n'est jamais un problème jusqu'à ce qu'il change la version de la plate-forme de base)

nous n'utilisons pas de branches non plus, car nous avons tendance à travailler sur la version head de chaque module, si nous avons besoin d'une branche pour un ensemble majeur de changements, nous allons nous connecter au niveau de la base, on créerait une branche" base v2 - performance " et tout le reste. Cela rend facile de grouper beaucoup de changements ensemble, car cela fonctionne de cette façon le mieux pour nous. Brancher des modules individuels entraînerait trop d'encombrement dans le repo - comme nous en avons quelques centaines, il serait facile de les perdre de vue si nous avions des branches par module.

Oui, nous faisons des changements sur le tronc, mais c'est ok avec notre workflow - les choses ne sont pas engagées jusqu'à ce qu'elles soient prêtes à aller. Tous les changements qui sont nous avons trop de modules pour les gérer dans un cycle complet dev-test-release. On répare, si ça s'avère être une mauvaise réparation, on répare à nouveau. Nous changeons parfois cette approche pour des développements plus importants et créons une branche sur un dossier branches (hors de la racine). Le chemin de la branche crée de nouveau le chemin vers le module original (il est donc facile de savoir qui il est, et fusionner en arrière est aussi facile que changer / branches vers / tronc au début de la chemin.)

le seul problème que nous avons rencontré dans ce système est lorsque nous mettons un module dans le projet d'une application web (redmine). Nous voulions avoir un seul projet redmine pour toutes les versions d'un module, mais notre disposition était telle qu'il est devenu un peu difficile de donner une racine du référentiel. Si nous pouvions associer un chemin repo à chaque version dans redmine, alors cette limitation disparaîtrait.

ce N'est pas nécessairement le meilleur pour tout le monde, et je recommande d'utiliser les branches plus, mais cela fonctionne pour nous (en partie parce que c'était la façon dont nous avons travaillé dans un système de contrôle source antérieur qui était "sécuritaire" et qui ne soutenait pas les branches/la fusion).

j'ai tronc, les branches, les balises et espaces de travail sous la racine du dépôt.

• tronc - pas utilisée pour éviter une confusion
• les branches libération branches, l'une libération de la vie est d'environ une année, nommé par le nom du produit l'acronyme et de l'année en cours (LDN_FSHCHPS_REL_2010)
• les balises - étiquettes de mise en circulation/correctifs immuables (fait avec svn copie), générée automatiquement à partir de l'horodatage (LBL_20100526180134 = 2010-05-26 18:01:34), les versions de versions sont générées à partir de la même horodatage comme v10.05.26.180134 il est donc facile de map label à la version
• espaces de travail - la fonction / les branches du développeur individuel, poussent à partir des branches / LDN_FSHCHPS_REL_2010 pour le nouveau développement ou à partir de tags / LBL_20100526180134 pour la correction, la ramification est faite avec svn copy, backmerge -- svn fusionner, La réintergration se fait avec svn merge --réintégrer. les espaces de travail sont nommés de la même façon que WS_ où ils sont générés automatiquement par script (comme auto-développement)

tout est dans un dépôt unique avec horaire/quotidien/etc. sauvegarde. Toutes les étapes telles que la création de branches, l'étiquetage, la fusion et la construction sont scriptées pour des raisons de commodité et de stabilité (les scripts vérifient la cohérence du dépôt).

branchement / Fusion autorisé pour les répertoires de deuxième niveau seulement, et seulement complète fusionne, et non les fichiers/répertoires (dites branches/LDN_FSHCHPS_REL_2010 --> espaces de travail/WS_345) pour activer la commande automatique de la fusion et pour éviter des problèmes avec les sous-arbre de fusion d'informations (et aussi pour faciliter la rootcausing de la fusion des problèmes quand ils arrivent)

en ce moment, nous employons les normes suivantes avec SVN...

normalement, les Tags sont mutables. La raison pour laquelle vous étiquetez une version est que vous pouvez appliquer des corrections de bug pendant que le développement se poursuit sur le tronc. Bien sûr, les mêmes corrections de bugs doivent être appliquées au tronc.

donc, si votre projet est quelque chose comme le baseball de jardin pour Youngins, comment vous y prenez-vous?

nous sommes une boutique Java, donc tous nos projets sont nommé gov.bop.projet. :- ) Subversion fonctionne avec tous les noms.

si vous utilisez le paradigme des branches de fonctions, comment nommez-vous vos branches de fonctions?

nous suivons le nombre généré par notre système de rapport d'incident. Cela facilite la vérifiabilité.

les Tags semblent bénéficier le plus des numéros de version.

nous avons constaté que les dates AAAAMMJJ fonctionnent mieux sur une longue période.