Deux équipes travaillent sur deux projets différents "A" et "B". Certains fichiers sont communs aux deux projets et sont stockés dans un répertoire "Common". Lorsqu'une date de sortie du projet A approche, l'équipe du projet A ne veut pas être dérangée par les modifications apportées à "Common" par l'équipe "B".Créer un répertoire SVN localement en lecture seule
La plupart des gens aiment les branches pour ces problèmes, mais je ne le fais pas. Ce que je veux est de donner une possibilité simple de faire équipe A à
1) ignorer toutes les modifications apportées par l'équipe B aux fichiers communs
2) partager les modifications de fichiers communs entre l'équipe A membres
Voici A, B, répertoires communs comme stockés sur svn:
Common
.. A
.. B
l'idée que je suis en train de mettre en œuvre est-à-créer le répertoire « Common » lecture seule et non actualisable à l'équipe A. S'ils veulent vraiment modifier les fichiers communs, ils devront les copier dans le répertoire "A" et les valider.
Existe-t-il un moyen, idéalement simple et élégant, de faire "juste ça"?
NB: ceci est une présentation simplifiée du problème. Il y a plus que deux équipes, et plus qu'un seul référentiel « commun »
NB2: toutes les équipes utilisent tortoiseSVN
Cela semble être exactement ce pour quoi les branches ont été inventées. Pourquoi pensez-vous que vous ne les aimez pas utiliser alors? – sbi
En utilisant les branches, aucune différence ne peut être trouvée lors de la modification de A ou Common. Je veux le rendre légèrement plus difficile à modifier Common (juste pour s'assurer que le développeur réfléchit un peu avant de le faire) –