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.