Discussion :

[zax-tfh]

Bonjour à tous,

Je suis face à une problématique avec VisualSVN :
J'ai un dépot par projet commun à chaque developpeur.
Chacun fait sa sauce en utilisant les projets qu'il veut.
Maintenant, admettons qu'un dev ait à maintenir plusieurs projets dans une solution. Le soucis qui se pose est que VisualSVN ne gère qu'une Working Copy à la fois... Je ne peux pas par exemple faire de modif sur un projet, faire mon commit puis passer direct à l'autre projet et faire mon commit aussi pour ce deuxieme projet.

Auriez vous déjà rencontré ce problème et avez vous trouvé une solution ?
Merci d'avance
@+

[SaumonAgile]

C'est parce que le fait d'avoir un dépot par projet est une erreur au départ. SVN est capable de gérer de gros projets dans le même dépot (exemple, le dépot mozilla).

[zax-tfh]

Tu m'interresses SaumonAgile :p tu m'as l'air de bien connaitre subversion !
En fait si j'ai fait un dépot par projet c'est très simple :
Je ne veux pas que tous les projets prennent une révision de plus alors que je n'en ai modifié qu'un seul... Chacun doit avoir son numéro de révision, chacun doit être manipulable séparement. Qu'en penses tu ? y'a-t-il une autre démarche que celle que j'utilise pour arriver au même but ?

Ah oui et aussi : je ne veux pas que tout le monde ait tous les projets dans un repertoire, si untel ne veut que 2 projets sur les 30 ou 40, j'aimerai qu'il puisse choisir.

Merci

[SaumonAgile]

Je ne vois vraiment pas en quoi le fait que les projets partagent un numéro de révision est une problème. Tu es en train de te créer de faux problèmes. Ceci n'empèche en rien les projets d'être distincts. Une révision n'est qu'un patch appliqué sur certains fichiers. Après que cette révision concerne les fichiers du projet A ou B, honnêtement, du point de vue du source control, on s'en f.... On utilisait Bugzilla conjointement avec SVN, et que la révision N, N+2 appartienne au projet A et la N+1 au projet B, ça n'a strictement aucune importance.
Quand tu achètes 2 litres de lait, tu ne vas pas harceler la vendeuse pour avoir des numéros de fabrication consécutifs.

Quand au problème de récupérer toutes les sources ou pas, tu n'es pas obligé de faire un checkout sur tout le dépot, tu peux faire n checkout sur n sous répertoire, encore une fois, tu te crées des problèmes là où il n'y en a pas.

[zax-tfh]

Merci SaumonAgile pour cet éclaircissement.
Alors pour ce qui est de me créer des problèmes, en fait ce n'est pas volontaire, j'apprend à connaitre subversion et je dois dire qu'il faut que je me presse car on me pousse un peu derriere, donc un peu de mal à tout saisir à la volée

Pour ce qui est du multi dépot, je veux bien croire que le numéro de version on s'en tape un peu. Par contre, je viens d'essayer une chose :
J'ai ajouté quatres projets sur un meme dépot.
Sur une autre machine, je créé une nouvelle solution dans laquelle je fait un projet nouveau. Je souhaite ajouter ce projet au dépot, donc via VisualSVN, je clique sur Add to Repository. Là je met l'url du dépot en question et c'est parti. Sauf que quand je regarde en local, il m'a téléchargé tous les autres projets (les 4 qui résidaient déjà sur le dépot).
Mon problème c'est que je ne veux pas rapatrier tous les projets sur chaque machine. Est-ce un comportement normal ou pas de subversion/VisualSVN ?
Merci

[SaumonAgile]

Avec tortoisesvn, ce n'est pas un fonctionnement par défaut, quand tu crées une copie locale, tu n'es pas obligé de récupérer le répertoire de base, tu peux ne récupérer que le sous-répertoire qui t'intéresse. Après je ne peux pas dire si Visual SVN se comporte obligatoirement comme ça, je ne m'en suis jamais servi.

[BlakDrago]

Le fait qu'il télécharge l'ensemble du dépot me semble normal. Pour pouvoir ajouter ton nouveau projet, il a besoin de savoir où il se trouve par rapport aux autres (si tu le déplace dans le dépot, il sera déplacé sur le disque). Si je comprend ce que tu essaie de faire, je pense qu'il faut que tu crée un dépot par projet, ce qui est, selon moi, difficilement gérable. Le but d'un système de versionning est de pouvoir assurer la cohérence de l'ensemble. Si tu veux récupérer une version d'il y a deux mois, aucun problème puisque tu récupére une révision cohérente alors qu'en démultipliant les dépots, tu te retrouve à devoir chercher pour chacun des projets la bonne révision, ce qui nécessite un gros travail documentaire.

Comme le dit SaumonAgile, je pense que ta vision de départ est fausse. Il faut un dépot global pour tous les projets (c'est que l'on fait dans mon entreprise, il y a environ 150 projets individuels). Cela n'empeche pas de creer un dépot par personne pour sauvegarder le travail au fur et à mesure. Par exemple, tu as un dépot commun avec tous les projets, et un dépot par service (personne) permettant de désynchroniser les livraisons.

En ce qui concerne le multi dépot, TortoiseSVN (et donc VisualSVN) se base sur les informations présentes dans les sous répertoires .SVN, ce qui permet de combiner plusieurs dépot dans les même solution

J'espere que cela répond à tes interrogations.

---
BlakDrago

[SaumonAgile]

Cela n'empeche pas de creer un dépot par personne pour sauvegarder le travail au fur et à mesure. Par exemple, tu as un dépot commun avec tous les projets, et un dépot par service (personne) permettant de désynchroniser les livraisons.

Créer un dépot par utilisateur ?
Si vraiment tu veux sauvegarder ton travail, soit tu utilises un logiciel de backup, soit tu archives des patchs dans le dépot principal.
Un dépot par personne, c'est le risque de générer des heures de diff/patch/merge/conflict pour pas grandchose.

[BlakDrago]

C'est pour cela que j'ai précisé également service, dans le cas où il faut partager le travail. Dans notre entreprise, j'ai un repository pour le service (je suis seul dans le service) mais j'utilise les projets du tronc commun. Mes modifications sont donc stockées dans un dépot SVN pour être ensuite, après validation, remise dans le dépot commun.

Je n'ai peut être pas été assez clair sur ce point.

---
BlakDrago

[zax-tfh]

Merci pour toutes ces indications !
Alors ce matin (et une partie de l'apres midi), j'ai fait des essais.
En fait l'utilisation de VisualSVN bride à mort l'utilisation de subversion en imposant sa façon de faire.
Je vais vous donner le cas concret que je rencontre :
En local, J'ai un repertoire "Mes projets" saucissonné en sous repertoires comme suit :

Mes Projets
-Projet1
-Projet2
-Projet3 (inclus projet1 et projet2)

Moi je développe Projet3 qui est un projet à part entiere mais qui se base tout de meme sur projet1 et projet2.
Ce que j'ai fait selon vos conseils est que en gros mon dépot correspond à Mes Projets.
Maintenant, je dois intégrer une 40aine de projets (dont projet1 et projet2 qui ne sont en fait pas de moi mais de mon collègue).
Donc mon dépot va etre comme suit :

Mes Projets
-Projet1
-Projet2
-Projet3 (inclus projet1 et projet2)
-Projet4
-Projet5
-....
-Projet43

Moi perso j'ai toujours mes 3 projets en local ce qui me va bien, j'ai pas besoin des 40 autres.
Aujourd'hui je n'utilise que TortoiseSVN de cette maniere :
Si je veux récupérer un projet et travailler avec/dessus, je créé un repertoire vide en local sous Mes Projets puis je fais un checkout sur http//mondepot/le_projet_à_recuperer et ensuite, une fois récupéré je l'intègre comme si on me l'avais filé par une clef usb ou un HDD externe.

Maintenant pour ce qui est de Visual SVN, c'est une autre paire de manches...
VisualSVN se base sur la solution, non pas sur les projets. C'est là ou ca coince.
Si ma solution comporte les projets 1, 2 et 3, ils ne sont pas tous dans le repertoire de ma solution. Là j'ai deux options :
1) je stocke ma solution à la racine du repertoire Mes Projets (ce qui fait que j'ai tous mes projs au meme niveau)
2) Je stocke ma solution dans un sous repertoire de Mes Projets (mais là c'etst le binz).
Explications :
Avec la solution 1, vu que ma solution est à la racine du dépot, quand je vais faire un commit, que je n'utilise que deux ou 40 projets, ca ne fera pas de différence, VisualSVN me télécharge tout le depot => j'en veux pas (y'a 10Go donc faut pas abuser...)
Avec la solution 2, ma solution étant dans un sous répertoire de Mes Projets, VisualSVN ne voudra synchroniser que ma solution et pas mes projets qui sont hors de mon repertoire de solution. "Normal" me direz vous. Oui et non... Quand on travaille sur un projet au sens large du terme, on peut travailler sur plusieurs projets au sens Visual Studio du terme. Donc on peut souhaiter faire un commit de tous ses projets en cours. Or comme ils ne sont pas en dessous du repertoire de la solution mais à côté, VisualSVN n'est pas content.

Dans la FAQ VisualSVN il parlent bien d'une propriété svn:external mais j'avoue que pendant les tests j'ai trouvé le comportement assez louche...
Utilisez vous cette propriété ?

Merci encore pour votre aide et le feedback de vos experiences !

[BlakDrago]

Je vais regarder cela demain au taf, cependant 10Go pour 40 projet ca me parait quelque peu énorme, il faut exclure tous les fichiers bin, obj, ... ce n'est pas fait de manière automatique, il y a une option (global exclude) pour cela.

Nous avons quelques 150 projet mais au grand maxi 250Mo de source (avec quelque redistribuable ...).


Je pense que cela te limitera grandement ce qui est archivé sous SVN.

Bonne soirée

---
BlakDrago

[zax-tfh]

Oui en effet, les 10Go ce sont les projets de mon boss, mais il doit y avoir une bonne partie de binaires inutiles et autres projs de tests...

Pour le global exclude c'est fait ^^ j'ai repris le meme que VisualSVN mettait en place.

Quand tu dis "je vais regarder ça demain au taf" tu parles de quoi ? de la taille ? car à la limite ce n'est pas une question de taille. C'est surtout une question de pouvoir avoir uniquement les projets que l'on souhaite avoir et pas le reste.

Si tu peux me décrire ta structure de dépot/working dir (un peu de la meme maniere que je l'ai fait dans le precedent post), ça m'interresserai bien car je t'avouerai que je ne vois vraiment pas de façon de travailler interressante avec VisualSVN...

Merci !

[BlakDrago]

Notre archi SVN ressemble à cela

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
\Root
    \Archi
        \Projet1
        \Projet2
        ...
    \Soft
        \Tags
        \_Composant Communs
            \ProjetCC1
            \ProjetCC2
            ...
        \Projet1
        \Projet2
        ...

Personnellement, j'ai l'intégralité de l'arbre SVN pour travailler. Le boulot le plus important est, je pense, d'utiliser SVN convenablement. Ca me parait étrange des 10Go dans l'archive SVN, je pense que tu peux aisément isoler les binaires du reste de l'arborescence.

Je dirais que si ton soucis ne vient que de VisualSVN, ne l'utilise pas ... toutes les actions que tu fais avec VisualSVN, tu peux les faires avec TortoiseSVN dans l'explorateur Windows (c'est ce que j'ai fait au début quand j'ai travaillé sur la refonte de l'architecture de l'application).

Je ne vois pas quoi ajouter de plus, c'est surement que l'outil n'est pas adapté à ton besoin, c'est tout.

---
BlakDrago

[zax-tfh]

Salut BlakDrago,

Merci de ta réponse. Heureusement, sur l'email de notification il y a les tabulations pour l'arborescence (elle n'apparaissent pas ici... dommage) sinon je n'aurais rien compris !

Alors en fait je pense que nous avons la même façon de voir les choses, sauf que moi je débute avec Subversion ^^
Par rapport à ton arbo, est-ce que Projet1 peut faire appel à des choses contenues dans _Composant Communs mais surtout, _Composant Communs est il un repertoire contenant plusieurs projets de composants que tu aurais créé ?
En fonction de ta réponse, je verrai si on est toujours dans le meme cadre d'utilisation et donc je pourrais te poser une question plus ciblée.
Merci !

[BlakDrago]

Le répertoire composant communs contient plusieurs projet différents, et tous les autres projets références des projets du répertoire composant communs. De plus, chaque projet contient plusieurs projet ...

---
BlakDrago