2017-09-16 26 views
2

Depuis quelques semaines, j'ai des problèmes avec Subversion. Lorsque j'essaie de valider des fichiers à partir d'un projet Visual Studio 2017, il existe certains fichiers que je ne peux pas valider sur mon serveur Visual SVN. Pour être précis tous les fichiers dans le dossier du projet comme .cs *, * .config, * .csproj, * .resx, ...Impossible de valider plusieurs fichiers du projet Visual Studio vers subversion

Ma configuration:
Client: TortoiseSVN 1.9.7 sur Windows 10
serveur: VisualSVN derrière un exécutant IIS-proxy inverse sur Windows Server 2012r2

l'erreur que je reçois lorsque je tente de commettre par exemple un fichier * .cs:

Commit 
D:\Test\branches\ScaraControl\ScaraControl\Form1.cs 
D:\Test\branches\ScaraControl\ScaraControl\Form1.cs 
Commit failed (details follow): 
File 'D:\Test\branches\ScaraControl\ScaraControl\Form1.cs' is out of date 
'/svn/Test/!svn/txr/5-9/branches/ScaraControl/ScaraControl/Form1.cs' path not found 
You have to update your working copy first. 

Mise à jour de la copie de travail est terminé avec succès, mais qui ne fonctionne pas résoudre le problème.

Vous pouvez voir mon projet dans l'image ci-dessous. Pour tester, j'ai créé un référentiel complètement nouveau et vide. Comme vous pouvez voir les dossiers .vs, bin et obj sont ignorés avec tous les fichiers à l'intérieur d'eux, tous les autres dossiers sont validés sur le serveur (sans les fichiers à l'intérieur d'eux). Dans la deuxième image, vous pouvez voir que je peux valider le fichier * .sln mais aucun autre fichier dans le dossier du projet.

enter image description here enter image description here

Pour les tests, j'ai créé un fichier texte vide et rebaptisés à text.cs. Même ce fichier vide ne peut pas être validé sur le serveur avec le même message d'erreur. En raison du fait que cela arrive à tous les clients, il est plus probable qu'il s'agisse d'un problème côté serveur, mais je n'ai aucune idée de ce qui pourrait causer cette erreur. Malheureusement, le serveur VisualSVN n'a pas d'erreur de journalisation ou du moins pas la version gratuite que j'utilise.

Je serais très reconnaissant pour tout conseil que je peux obtenir pour résoudre ce problème ennuyeux.

Edit1: Le problème est causé par l'IIS Reverse-Proxy

Après la connexion via le port 8443 directement au serveur VisualSVN (sans passer par le proxy inverse) tout fonctionne à nouveau. Il doit donc y avoir un problème avec la configuration du module URL Rewrite. Pour être honnête, il m'a fallu beaucoup de temps pour que ça marche parce que ma connaissance de tous les paramètres est très limitée.

Ceci est mon Web.config avec les paramètres pour le module URL Rewrite. Peut-être qu'il y a quelque chose qui n'est pas configuré comme il se doit. Si vous avez besoin de plus amples informations, il suffit de demander.

<?xml version="1.0" encoding="UTF-8"?> 
<configuration> 
    <system.webServer> 
     <rewrite> 
      <outboundRules> 
       <rule name="ReverseProxyOutboundRule1" preCondition="ResponseIsHtml1" enabled="true"> 
        <match filterByTags="A, Form, Img" pattern="^http(s)?://svn.example.org:8443/(.*)" /> 
        <action type="Rewrite" value="http{R:1}://svn.example.org/{R:2}" /> 
       </rule> 
       <preConditions> 
        <preCondition name="ResponseIsHtml1"> 
         <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" /> 
        </preCondition> 
       </preConditions> 
      </outboundRules> 
      <rules> 
       <rule name="ReverseProxyInboundRule1" enabled="true" stopProcessing="true"> 
        <match url="(.*)" /> 
        <conditions> 
         <add input="{CACHE_URL}" pattern="^(https?)://" /> 
        </conditions> 
        <action type="Rewrite" url="{C:1}://svn.example.org:8443/{R:1}" /> 
       </rule> 
      </rules> 
     </rewrite> 
     <security> 
      <authorization> 
       <remove users="*" roles="" verbs="" /> 
       <add accessType="Allow" users="" roles="Users" /> 
       <add accessType="Allow" users="*" /> 
       <add accessType="Allow" users="?" /> 
      </authorization> 
     </security> 
     <urlCompression doStaticCompression="false" doDynamicCompression="false" /> 
     <httpRedirect enabled="false" destination="https://svn.example.org" exactDestination="true" childOnly="true" /> 
     <directoryBrowse enabled="false" /> 
    </system.webServer> 
</configuration> 
+0

. Pour voir les journaux, vous devez ouvrir l'observateur d'événements à partir du panneau de configuration (gestion de l'ordinateur), puis sélectionner les journaux d'application et de service. – royalTS

+0

Hey merci pour le conseil mais j'ai déjà vérifié le journal des événements. Il n'y a aucune erreur ou quelque chose qui pourrait aider, seulement quelques journaux avec le service en cours d'exécution/en pause. –

+0

VisualSVN Server a la journalisation des erreurs en édition Standard gratuite. S'il n'y a pas d'erreurs dans le journal, j'essaierais de rechercher ce que fait le proxy inverse IIS. Pourrait être une mauvaise configuration de son côté. – bahrep

Répondre

1

je suis tombé sur le même problème et suis en cours d'exécution d'un proxy inverse via IIS, donc croire que quelque chose à voir avec elle.

VisualSVN est servi localement sur https://localhost:8443 et j'essayais d'utiliser le proxy inverse pour acheminer de https://svn.mysite.com. Ce apparaît pour fonctionner correctement. Vous pouvez même extraire une nouvelle copie du repo et tous les fichiers sont téléchargés. C'est lorsque vous essayez et vous engagez que vous avez des problèmes - comme vous l'avez identifié, certains fichiers ne peuvent pas être trouvés sur le repo.

Le seul travail que j'ai trouvé (merci à votre question de réduire les causes probables) était d'ajouter le port à l'adresse URL: https://svn.mysite.com:8443. Cela ne devrait pas être nécessaire car le proxy inverse devrait gérer, donc je suppose que c'est un problème avec VisualSVN qui pourrait être corrigé dans une future mise à jour. VisualSVN Server enregistre dans les événements de Windows

+0

La connexion via le port 8443 directement au serveur VisualSVN fonctionne comme il se doit. Il doit y avoir quelque chose de mal avec mes paramètres de proxy inverse. Je vais mettre à jour ma question avec plus d'informations. –