Configuration du serveur VisualSVN pour utiliser _svn au lieu de .svn

Question

Nous avions un problème avec notre serveur de build qui ne vérifiait pas les modifications du contrôle de code source même s'il reconnaissait qu'il y avait eu des changements.

Il a été tracé jusqu'au dossier de contrôle (je ne suis pas sûr de son vrai nom), les versions de travail existantes utilisaient _svn.La suppression du dossier de travail a forcé une nouvelle extraction complète et j'ai remarqué que le dossier de contrôle est désormais .svn.Il semble qu'à l'origine nos routines d'intégration extrayaient le code en utilisant _svn, mais maintenant elles utilisent .svn.

Le svn.exe utilisé lors de l'intégration provient de VisualSVN Server. Puis-je le configurer pour utiliser à nouveau _svn ?

Comment les copies de travail originales utilisaient _svn, je ne sais pas !- nous n'avons utilisé que VisualSVN Server et nous n'avons rien changé à cela.

Nous avons configuré TortoiseSVN pour utiliser _svn en suivant la recommandation selon laquelle cela fonctionne mieux pour Visual Studio et avons également installé TortoiseSVN sur le serveur de build au cas où cela serait nécessaire.Cela pourrait-il être la cause?

Et est-ce vraiment nécessaire ?Comme MSBuild appartient à Microsoft, est-il recommandé comme pour Visual Studio ?

Answer 1

L'affaire concernant _svn vs..svn était un problème avec les projets Web Visual Studio uniquement (et je suis presque sûr qu'il a été corrigé dans VS2005 de toute façon), ce n'est pas un problème général "_svn fonctionne mieux avec VS".

Il s'agit également uniquement d'un problème de copie de travail, pas d'un problème de référentiel - c'est-à-direpeu importe si certains utilisateurs de SVN utilisent des clients configurés pour faire _svn et d'autres utilisent .svn - le référentiel ne le saura pas ou ne s'en souciera pas - (à moins que vous vous retrouviez avec une charge de ces _svn/.svn fichiers réellement archivés dans le référentiel, ce qui serait extrêmement déroutant.)

À moins que vous n'ayez des preuves concrètes et absolues que .SVN vous pose des problèmes, je m'en tiendrai à cela autant que possible.

Answer 2

J'utilise .svn avec Visual Studio 2008 et 2005 ainsi que sur notre serveur d'intégration CC.Net (avec MSBuild) sans problème.Je m'en tiendrai au format .svn.

Answer 3

http://subversion.tigris.org/svn_1.3_releasenotes.html

Besoin de lire la section "Prise en charge officielle de la prise en charge officielle de Windows '_SVN (liaisons client et linguiste)"

Et vous devez être conscient que vous lisez une documentation vieille de plusieurs années, un fait qui peut être pertinent ou non.

Answer 4

Autant que je sache, _svn est nécessaire, car les applications Web ont des problèmes lorsqu'un de leurs répertoires commence par un point.