Reprise du message précédent :

prems

dormir

 
T'as un peu regardé House alors ?

parlay bordayle  

salut

salut

salut

salut

salut

bon vol [/11/9/2001]

nan
je regarde juste un episode ou deux de temps en temps
fake edit: http://fr.youtube.com/watch?v=1YUvo7YxqwM
pt1 mais j ai vu la moitié de ces episodes
en fait c ets un jeu où faut repérer a quel moment de l episode ils en parlent quoi

salut  

http://scienceblogs.com/loom/2008/ [...] lution.php

I'm in your beaker, eating your citrate... OM NOM NOM

salut
 

salut

 
Wé, spa toujours un lupus sinon ça serait trop facile  

¿¿¿ŀŀŀŀŀŀŀŀŀŀŀŀŀŀ
Bonjoir.
↓↓↓↓↓↓↓↓↓
 
Tout le monde va bien? [:

salut

 
Touche tab  

salut

J'suis le seul a trouver que le niveau moyen sur ce topic s'est effondré depuis la récente paternité de certains participants ?

masklinn

 
C'était le précédent sondage, qui a abouti sur une commande groupée de congélateurs.

quoi  

 
tu n'as posté une dizaine de messages sur les 80 dernières pages, tu vas être papa ?  

Le mec qui a pondu notre architecture svn, mais c'est un grand malade, quoi!

On a bien les répertoires Branches / Tags et Trunk, mais c'est tout, après c'est n'importe nawak.

Dans branches, y'a "projects" et "products", dans lesquels, y'a un répertoire par produit (une appli, quoi) ou par projet (une appli pour un client donné) Dans chacun de ces répertoires, y'a un répertoire par branche, et là dedans...........des liens vers des répertoires de trunk!

Et dans trunk, y'a un répertoire par ensemble de sources/resources, etc..., qui contient un répertoire par branche qui a existé.

C'est la fête!

 
Des indices sur ce qu'il ne faut pas faire ? J'en ai une en préparation.

 
Une branche par commit, avec comme nom le numéro de révision, histoire de pouvoir naviger dans les versions sans tapper sur le serveur, simplement avec l'explorateur de fichiers  

 

 
Le coup de 1 branche par commit, CMSynergy le fait déjà, donc là-dessus ça va, j'suis vacciné.

http://svnbook.red-bean.com/en/1.4 [...] int.layout
edit : ou plutôt http://svnbook.red-bean.com/en/1.4 [...] ooselayout

Ah bah oui, en plus j'ai déjà du le lire je pense. Faudra que je repotasse ce bouquin au moment de la mise en place... si j'ai un serveur. Un jour. Peut-être.

 
j'étais dessus....Mais ça m'éclaire pas sur ce qui a pu passer par la tête de mes brillants architectes sur ce coup là!

En clair, il a tout inversé

Le "best practice" subversion de base est pas très compliqué:

Tu crées une arbo de projets (un répertoire par projet, il est possible de regrouper les projets dans un même répertoire e.g. tous les projets du/pour le même client, surtout si il en a beaucoup).

Pour un projet donné, un répertoire "trunk" dans lequel va le trunk, un répertoire "branches" dans lequel tu colleras les branches et un répertoire "tags" pour... les tags \o/

Donc au final, imaginons que la boite a 4 projets en cour, 1 projet Foo qui a déjà eu 2 grosses releases (1.0 et 1.1) avec quelques releases intermédiaires (taggées), 1 projet Bar qui n'a pas encore eu la moindre release, et 2 projets "BlogBlog" et "OmNomNom" faits pour la Fnac, le premier ayant déjà eu une release unique et le second ayant eu 3 releases "majeures" (0.9, 1.0 et 2.0) et quelques releases intermédiaires, tu vas avoir un layout de ce style:

Après tu peux aussi avoir des variations sur thème: à la racine de ton repo, au lieu d'avoir les projets tu colles un répertoire "projects", un répertoire "clients" et ptet un répertoire "dox", dans projects t'as tous les projets, dans clients t'as tous les clients, mais (trick \o/) dans le répertoire d'un client il y a des svn:externals sur les projets faits pour lui.

Donc avec l'exemple précédent, en considérant e.g. que Foo est un projet pour Lagardère et Bar est un projet pour SNCF, tu vas avoir un truc genre:

(j'ai créé des symlinks pour la démonstration, mais faut utiliser des externals ou Piston, vu que les symlinks sont pas gérés sous windows par SVN)

Tu peux aussi avoir d'autres "meta-layouts", mais le plus important c'est que le layout de chaque projet soit standard (trunk/branches/tags)

Je suis complètement d'accord avec ce style  

J'suis un pauvre lurkeur, loin d'avoir le niveau pour intervenir de façon régulière sur ce topic d'experts

Noter que dans les variations, il est possible de considérer des trucs comme: vaut mieux mettre la doc d'un projet avec le projet, ou dans un répertoire de dox séparé? Ce répertoire de dox séparé va-t-il mirrorer le répertoire de code ou avoir un layout complètement distinct dépendant des besoins des consultants et du process marketting? etc...
 
Mais t'es pas non plus obligé de réussir du premier coup, tant que ton repo a pas atteint une taille trop gigantesque tu peux le retravailler à coup de svn mv sans perdre ton historique

 
Mouais, ça j'aime pas.
 
Parce que là, t'as bien pris soin que les mêmes projets ne soient pas partagés entre tes clients....
Imagine que ça soit le cas : tu checkoutes Fnac et SNCF, qui contiennent chacun BlogBlog, plus des trucs spécifiques.
 
Si tu fais une modif dans BlogBlog pour corriger un bug à la Fnac, et que tu veux vérifier que t'as pas de régression à la SNCF, comment tu fais? T'es obligé, soit de coier/coller tes modifs dans la working copy de SNCF, soit de commiter ta working copy de FNAC, updater ta working copy de SNCF, et tester.
 
C'est lourd.
 
Du coup, je sais pas trop comment m'y prendre!