Salut,
au boulot, svn est de rigueur pour les développeurs (que le projet soit gros ou plus modeste). C'est, dans un sens, plutôt une bonne chose. Sauf que, je ne connais pas svn (je suis plutôt darcs). Je dois faire rentrer dans un unique dépôt, l'ensemble des développements que notre équipe a pu faire depuis des années. J'avais déjà fait l'exercice par le passé dans git mais j'avais alors créé plusieurs dépôts (correspondant aux technologies pour lesquelles ces développements s'adressaient). Pour faire simple, je suis DBA et nous produisons des outils à destination de nos exploitants pour divers OS et divers SGBD.
Bref, comment organiser au mieux mon dépôt pour facilement nous y retrouver. Aujourd'hui, le dépôt est organisé comme suit:
dba_w9n/
branches/
tags/
trunk/
Mes "modules" sont multi-versions et indépendants. Je peux avoir un projet mysql_tb en v01_00_00 et dans le même dépôt le projet oracle_rac11g en v00_01_00. Comment faire usage des tags pour ne pas me trimballer 10ans de développement au moindre checkout et comment être sûr que le tag v00_01_00 ne contiendra pas autre chose que le code pour le rac ?
Merci
# Un dossier par module
Posté par Michaël (site web personnel) . Évalué à 3.
dba_w9n/{mysql_tb,oracle_rac,…}/{branches,tags,trunk}
SVN ne garde que HEAD dans le checkout, donc tu ne vas jamais sortir 10 ans de dév.
Tu checkoutes seulement le module que tu veux.
Entre cette organisation, et l'organisation «un repository par module» la différence est mince — est concerne essentiellement l'admin des dépôts.
Tu peux avoir plusieurs dossiers de branches, par exemple pour trier les topic branches et les maintenance branches.
[^] # Re: Un dossier par module
Posté par Xavier Maillard . Évalué à 2.
Merci pour ton retour.
Je veux faire la chose la plus simple possible pour que n'importe qui dans l'equipe, puisse suivre aisement l'organisation.
Il semble effectivement qu'en adoptant ton organisation, les choses vont dans le bon sens.
Donc, je dois pouvoir avoir quelque chose comme ca:
Ceci me convient a ceci pres que la frontiere entre un ora9i et un ora10g est mince. Dailleurs le developpement de la partie ora10g est en partie base sur ora9i (c'est un fork-cp: cp ora9i ora10g et on repart). Tout comme le so/ora11g est un "fork" de cc021/ora10g. Comment gerer cela correctement ? Il y a du developpement en commun (dailleurs il faudra probablement faire en sorte que tout cela fusionne pour ne pas garder trop de versions dans la nature).
Merci
[^] # Re: Un dossier par module
Posté par Michaël (site web personnel) . Évalué à 3.
Il faut commencer par définir «correctement»!
Du point de vue de ton SCM, ici Subversion, il s'agit essentiellement de se souvenir que ora10g est un fork de ora9i, ce que font (certainement) tous les SCM postérieurs à CVS, notamment SVN. (Avec svn cp …)
Le problème est que le fork est déjà fait, donc la question suivante est «comment importer l'hisotorique dans Subversion?» si cette historique existe! J'ai l'impression que ce n'est pas le cas, la solution suivante serait d'utiliser une sauvegarde antérieure au fork pour créer une historique artificielle qui permettrait de garder trace du fork dans Subversion.
Ceci dit, si deux arbres source sont aussi proches que tu le dis, on peut se poser la question de l'opportunité d'un fork. Il peut il y avoir de meilleurs moyens d'adapter votre logiciel à son environnement, par exemple avec du polymorphisme ou une configuration adaptée: le SCM n'est pas forcément le bon lieu pour régler ce problème.
J'ai vu dans un autre fil que tu répugnais à imposer à tes collaborateurs l'emploi des branches. Je te suis en partie, mais en principe le travail sur les branches n'est pas si difficile que ça — à une exception notable près: les merge, qui sont une opération plus délicate. Tu peux tout de même introduire les branches en désignant un petit nombre de «officiers de merge» qui sont plus à l'aise avec la technique et s'occuperont des merge, au besoin avec l'aide du développeur auteur des modifications.
Ceci dit, même sur un public de gens peu rompus à l'emploi des SCMs, des interfaces graphiques (intégration dans un explorateur de fichier) pour le SCM et un outil pour les merge permet à chacun de se débrouiller de façon honorable — dans cette solution, tu peux garder l'idée des «officiers de merge» qui épauleront leurs collègues en cas de difficultés.
# classé logiquement
Posté par NeoX . Évalué à 3.
gardé les developpements dans des branches par version ex 'v2.x.y'
utiliser les tags pour avoir 3 variantes :
- N+1 ou dev
- N version stable actuelle
- N-1 la version precedente
les versions plus anciennes etant dispo dans les branches par numero de versions
[^] # Re: classé logiquement
Posté par Xavier Maillard . Évalué à 2.
J'ai bien peur que les branches soient une fonctionnalite bien trop "avancee" pour notre usage et cela risque de serieusement compliquer le workflow. Ce n'est pas une population de developpeurs (au sens habitue aux outils specialises).
[^] # Re: classé logiquement
Posté par NeoX . Évalué à 3.
pourtant ils developpent bien un module particulier pour une version particuliere ?
donc tu peux coller des branches.
un module => une branche
mais habituellement on travaille avec des versions et on deplace la tete en fonction de ces versions.
bref, comme souvent, faut peut-etre reunir tout le monde autour d'une table pour debattre.
ben oui, y a ceux qui preferont ranger par :
- projet/modules/version
- version/modules
etc
[^] # Re: classé logiquement
Posté par Xavier Maillard . Évalué à 1.
Dans le fond, je suis bien d'accord avec toi mais je suis quasiment persuade que je vais perdre du monde en route avec svn alors imagine avec des techniques comme les branches…
[^] # Re: classé logiquement
Posté par totof2000 . Évalué à 4. Dernière modification le 22 mai 2012 à 16:19.
Pourtant, les branches c'est ce qui permet aux gens de se raccrocher lorsque tu les perds. A moins que tu scies celle sur laquelle tu es assis.
[^] # Re: classé logiquement
Posté par steph1978 . Évalué à 2.
Donc tu fais le choix de ne pas gérer de versions.
[^] # Re: classé logiquement
Posté par Xavier Maillard . Évalué à 1.
Euh, là je ne te suits pas. Que veux-tu dire ?
[^] # Re: classé logiquement
Posté par steph1978 . Évalué à 3.
si tu livre ton produit à partir de la révision 3455 du contenu du svn.
admettons que ça constitue la v1.
tu continues tes développement, sans faire de branche.
tu livres ton produit à partir de la révision 7537 du contenu du svn.
admettons que ça constitue la v2.
un bug est détecté sur la version 1.
comment construis tu la version 1.1 qui corrige la v1 ?
# rex
Posté par steph1978 . Évalué à 3.
"/trunk, /branches, /tags" est déjà un choix, puisque le repository démarre à "/".
Habituellement, je mets la version en cours de développement dans trunk.
Plutôt avec un répertoire par module/projet.
J'utilise branches pour les versions en qualification (version N-1) et production (N-2 à …) où je crée un répertoire par version (x.y.z) et en dupliquant l'arborescence de trunk au moment de la création de la branche (opération unitaire dans svn, il n'y a pas de duplication des données).
Je ne vois pas vraiment l'utilité de "tags" par rapport à l'usage qui en était fait dans cvs. Car je le trouve redondant avec l'information url_racine+révision. D'ailleurs, beaucoup de produits libres packagent avec la révision et non un numéro de version. Cela dit, je l'ai déjà vu utilisé pour marquer les livraisons en intégration ou qualification, embarqué dans le script de packaging pour éviter les oublis.
svn rocks.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.