Wault 6 Posté(e) le 31 mai 2011 Partager Posté(e) le 31 mai 2011 Bonjour à tous, Voilà voilà, j'utilise un serveur SVN tant bien que mal. J'utilise aussi TRAC pour la gestion de tickets, wiki, changeset, etc... Pour TRAC, j'ai bien créé un environnement différent pour chaque projet. Mais pour SVN, j'ai - bêtement - créé un dépôt, dans lequel j'ai créé des sous-dossiers pour chaque projet. Le problème ? Et bien il est lié à la révision des mise à jour dans le SVN. Exemple concret : Ajout de projet 1 dans SVN => révision passe à 1. Ajout de projet 2 dans SVN => révision passe à 2. changement dans projet 1 => révision passe à 3. changement dans projet 2 => révision passe à 4. changement dans projet 1 => révision passe à 5. => les deux projets sont à la révision 5 ! (en fait, c'est le dépôt principal qui est à la révision 5, tout simplement et logiquement). Or ce que je voudrais c'est que chaque projet soit totalement indépendant. Dans l'exemple précédent, projet 1 serait à une révision 3 et projet 2 à la révision 2. Je pourrais recréer de zéro des dépôts SVN à partir , mais voilà, j'ai déjà pas mal d'info en conjonction avec TRAC que j'aimerais garder tout en rendant les projets indépendants. Concrètement : un ticket indiquant le changement de la révision 4 pour projet 2 est lié à cette révision ou contient un lien vers le changeset de cette révision. En gros j'ai : projet 1, projet 2 à la révision 5 (avec donc des changements pour l'un et l'autre compris dedans). J'aimerais donc créer un dépôt pour projet 1 qui soit directement à la révision 5 pour garder l'historique de révisions. Idem avec projet 2. Et ils seraient donc indépendants. Est-ce possible selon-vous ? Et si oui, comment feriez-vous ? Il me semble que l'on peut gérer plusieurs dépôts avec un seul serveur SVN. J'ai tout à coup un doute, mais je suis quasiment certains de l'avoir vu dans une doc. Merci d'avance pour votre aide. Lien à poster
Dude76 19 Posté(e) le 1 juin 2011 Partager Posté(e) le 1 juin 2011 Désolé, on utilise svn au boulot, mais je ne me suis jamais penché sur la mécanique au-delà d'insérer les commandes pour les builds automatiques par copier-coller depuis un autre projet, et quelques lignes dans les fragments wix. Quand on arrête une version, on créé un branche, pour pouvoir y rapporter les éventuels correctifs (tags), et on continue le dév sur le trunk. (on utilise aussi hudson/jenkins). Lien à poster
Wault 6 Posté(e) le 3 juin 2011 Auteur Partager Posté(e) le 3 juin 2011 Et bien je vais devoir faire des tests par moi-même. ^_^ ça va être sportif la semaine prochaine. Lien à poster
Dude76 19 Posté(e) le 3 juin 2011 Partager Posté(e) le 3 juin 2011 Lundi j'essaierai de poser quand même la question à mon collègue polonais qui est un des deux ayant mis en place svn (& associés) en place. Il n'était pas là aujourd'hui (si même les polonais se mettent à poser des ponts, où va-t-on ? ), et de toute façon cette question m'était complètement sortie de la tête. Lien à poster
Dude76 19 Posté(e) le 11 juin 2011 Partager Posté(e) le 11 juin 2011 Bon, tout d'abord, désolé, mon collègue polonais est en congés depuis hier soir (pour 3 semaines ), et il est resté au boulot jusque 22h ces derniers jours; Il a bien vu que je lui ai envoyé un mail, mais n'a pas eu le temps de le lire, question de priorité Sinon, à relire ton message avec un peu plus d'attention, j'ai compris de quoi tu causes (bon, ok, c'était pas non plus ben compliqué ) Voilà comment nous on gère la chose (du moins de ce que j'en retiens), même si pour l'occasion ça nous arrange plutôt bien (on avait une autre organisation il n'y a pas longtemps, et elle s'approchait davantage de ce que tu voudrais): repositories _produit __trunk __branches ___v-1 ___v-2 ... __tags produit2 ... nous utilisons husdon/jenkins pour extraire les sources et automatiser les builds, les numéros de versions sont en partie figées par nous (en cohérence avec les versions dans les branches), et en partie par hudson qui récupère un modulo svn via le msbuild. un niveau produit recouvre un large ensemble de binaires, et il y a des références externe sur produit2; Quand on fige une branche, il faut régler les références externe vers le produit 2 vers le même niveau de révision. Les 2 avancent ainsi indépendamment (chacun son n° de build) et en gardant une corrélation entre les deux. Rien ne t'empêche de faire arriver chacun de tes dépôts dans des sous-dossiers (plutôt que "proche" de la racine de ton disque), ce qui te permettrai d'avoir des dépôts en parallèle (dont révisions séparées) tout en conservant la même structure arborescence qu'actuellement (donc conserver la validité des liens vers tes révisions). Lien à poster
Wault 6 Posté(e) le 12 juin 2011 Auteur Partager Posté(e) le 12 juin 2011 Bien vu ! Je vais tenter cette approche. De mon côté, je n'ai pas une organisation aussi complexe que celle que tu décris, puisque je m'occupe de projets web. C'est juste que, même pour du "simple" PHP, quand on commence à utiliser des frameworks (Zend), des librairies javascript, et qu'on doit tester sur des versions "test" avant de lancer la mise à jour en production, ben SVN ça rend bien service. Là je suis en train de mettre en place un combo TRAC-SVN aux petits ognons qui va me permettre, et aux collègues aussi, de travailler dans des conditions réellement "pro", parce que les demandes "vite-fait" au coin de la porte, ça gonfle quand-même un peu au bout d'un moment. Lien à poster
Dude76 19 Posté(e) le 12 juin 2011 Partager Posté(e) le 12 juin 2011 C'est clair ! (et à me relire je viens de voir le nombre de fautes ... mais j'ai la flemme de corriger ) Pour finir, un autre détail; S'il t'est possible, évite de séparer dans 2 dépôts différents les librairies communes et les projets qui les utilisent. Pourquoi ? pour la (les en fait) compilations automatiques. Je me base sur .Net pour mon propos. Si tu fais des références externes, alors que chaque projet faisant une référence externe, il va rapatrier les sources et les compiler avec le projet / la solution. Si tu laisses la source commune dans le même dépôt et te contente d'ajouter le projet dans la solution comme projet existant, il va ne le compiler qu'une seule fois pour l'ensemble de tes projets (et donc moins de variations sur les n° de builds générés). Un autre avantage, si tu modifies une source, tous les projets l'utilisant la verront également comme modifiée sans avoir besoin de faire un commit (depuis le projet où tu as fait ta modif) puis des updates (sur tous les autres projets l'utilisant); De plus, tu n'auras obtenu les sources que sur le projet "library" source, pas de (dizaines ? de ) copies locales via les références externes. Sur un temps de builds globales, c'est énorme le gain. Lien à poster
Messages recommandés