Question

J'utilise Subversion pour le contrôle de code avec TortoiseSVN pour m'interfacer avec le serveur depuis quelques mois, et en général ça se passe très bien !Cependant, il arrive parfois que mon IDE FoxPro change la casse d'une extension de fichier sans avertissement, où "programme.prg" devient "programme.PRG") TortoiseSVN considère apparemment que cela signifie que le premier fichier a été supprimé, étant signalé comme "manquant" et que le deuxième nom apparaît comme "non versionné", ce qui fait des ravages dans ma capacité à suivre les modifications apportées au fichier.Je comprends que Subversion a ses origines dans le monde sensible à la casse de *nix, mais existe-t-il un moyen de contrôler ce comportement dans Subversion ou TortoiseSVN pour que le nom de fichier ne soit pas sensible à la casse lorsqu'il est utilisé avec Windows ?

Était-ce utile?

La solution

Malheureusement, Subversion est sensible à la casse.Cela est dû au fait que les fichiers de Subversion peuvent être extraits à la fois sur des systèmes de fichiers sensibles à la casse (par exemple, *nix) et sur des systèmes de fichiers insensibles à la casse (par exemple, Windows, Mac).

Ce script de hook de pré-validation peut vous aider à éviter des problèmes lorsque vous archivez des fichiers.Si cela ne résout pas votre problème, ma meilleure suggestion est d'écrire un petit script pour vous assurer que toutes les extensions sont en minuscules et de l'exécuter à chaque fois avant votre enregistrement/départ.Ce sera un PITA, mais peut-être votre meilleur pari.

Autres conseils

Windows prend en charge la sensibilité à la casse, mais vous devez lui envoyer les indicateurs POSIX corrects sur CreateFile à partir de l'API Windows !Une clé de registre devra peut-être être modifiée (SFU/Tools for Unix et Ultimate Windows 7 a déjà défini cette entrée de registre afin que Windows prenne en charge les noms de fichiers sensibles à la casse).

Windows est conçu à partir d'Unix, mais des éléments tels que Explorer.exe et d'autres programmes sont conçus pour interdire la sensibilité à la casse pour des raisons de compatibilité ascendante et de sécurité (surtout lors de l'exécution de DOS notepad.exe vs.NOTEPAD.EXE, où toutes les majuscules désignent un virus ou un malware).

Mais Vista+ possède des attributs de sécurité qui rendent cela obsolète.

TortiousSVN ne prend tout simplement pas en charge la transmission de cet indicateur posix lors de la création et du renommage de fichiers.

J'utilise TortoiseSVN avec VFP, et il gère de manière transparente le retournement du cas.La seule fois où ce n'est pas le cas, c'est si le fichier est ouvert dans l'EDI lorsque j'essaie d'effectuer la validation :le verrou de fichier que détient VFP le confond.Est-ce là que se situe votre problème ou y a-t-il d'autres problèmes ?

J'ai fait une présentation à FoxForward l'année dernière sur l'utilisation de VFP avec Subversion :la majeure partie de la présentation traitait de la ligne de commande, mais il y a quelques diapositives à la fin qui contiennent des liens vers des outils qui vous aident à travailler avec Subversion dans VFP. http://docs.google.com/Presentation?id=dfxkh6x4_3ghnqc4

Je pense que les majuscules et les minuscules aléatoires sur les extensions ne sont pas du tout aléatoires.Je me souviens d'avoir testé ce sujet.Si vous modifiez un programme depuis le chef de projet.En cliquant sur le bouton modifier disons.Et puis enregistrez les modifications, l'extension est en minuscules.Si vous effectuez une commande de modification à partir de la fenêtre de commande et enregistrez les modifications, l'extension est en majuscules.Apparemment, les codeurs de Microsoft ne s'inquiétaient pas du fait que le cas d'extension soit le même.

Kit, vous commentez ci-dessus que les fichiers sources binaires de VFP sont difficiles à utiliser dans Subversion.Le lien que j'ai donné ci-dessus mentionne quelques outils pour faciliter les choses, mais celui avec lequel je travaille est l'utilitaire TwoFox de Christof Wollenhaupt - il convertit un projet VFP en texte uniquement.Vous devez l'exécuter manuellement, mais cela ne me pose aucun problème.

http://www.foxpert.com/docs/cvs.en.htm

Non, vous ne pouvez certainement pas.SVN est sensible à la casse, sauf si vous réécrivez le code d'une manière ou d'une autre...il est Open source.

Nous avons eu un problème similaire et je trouvé une meilleure solution que ceux exposés ici, donc je le partage maintenant :

  • Pour commits effectués manuellement, TortoiseSVN corrige désormais automatiquement la casse des noms de fichiers :il renomme les fichiers locaux pour qu'ils correspondent à la casse des fichiers versionnés (juste en ouvrant la fenêtre de validation dans ce chemin), il devrait donc y avoir aucun problème avec ça.

  • Pour validations automatisées vous ne pouvez pas utiliser TortoiseSVN, car cela vous oblige à confirmer manuellement la validation (cela ouvre la fenêtre de validation avec un message spécifique, mais vous devez toujours cliquer sur ok).Mais si vous utilisez directement Subversion (svn) pour effectuer une validation automatisée, vous rencontrerez alors un problème de sensibilité à la casse sur cette validation, car Subversion est toujours sensible à la casse...

Comment résoudre ce problème pour les commits automatisés ?Eh bien, j'ai essayé une approche mixte :créer un fichier batch appelé FixCaseSensitiveFileNames.bat que vous pouvez appeler en passant le chemin que vous souhaitez corriger avant la validation, par exemple : call FixCaseSensitiveFileNames.bat C:\MyRepo.Le fichier batch ouvre TortoiseSVN pour une validation manuelle, ce qui corrige automatiquement les noms de fichiers, mais il ferme ensuite la fenêtre de validation après une pause prédéfinie, afin que vous puissiez continuer la validation automatisée avec les noms de fichiers sensibles à la casse déjà corrigés.La pause est émulée avec un ping local et vous pouvez modifier la durée en modifiant le -n argument, qui est le nombre d’essais.Si vous ne faites pas une pause suffisamment longue, vous risquez de fermer la fenêtre TortoiseSVN avant qu'elle ne fasse sa solution magique.C'est ici le code du fichier batch:

@echo off
REM *** This BAT uses TortoiseSVN to fix the case-sensitive names of the files in Subversion
REM *** Call it before an automated commit. The Tortoise commit fixes this issue for manual commits,
REM *** so the trick is opening the commit window and close it automatically after a pause (with ping).
REM *** %1 = path to be fixed

start TortoiseProc.exe /command:commit /path:"%1"
ping localhost -n 10 >nul
taskkill /im TortoiseProc.exe

Cela a totalement résolu le problème de notre processus de construction quotidien automatisé.Le seul problème que je vois est qu'une fenêtre s'ouvrira pendant quelques secondes, ce qui n'était pas un problème pour notre build quotidien, mais si cela vous pose un problème, il pourrait également y avoir des solutions de contournement...

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top