Comment dois-je Fixer “svn: l'incohérence de fin de ligne de style”?

Quand je lance "svn propedit svn:ignore ." à la racine de mon dépôt svn, j'obtiens cette erreur:
svn: l'incohérence de fin de ligne de style

J'ai essayé d'exécuter ce script: http://blog.eflow.org/archives/130 qui s'exécute dos2unix et des jeux de l'eol-style sur tous les fichiers, mais ce problème persiste encore. Toute idée de ce que pourrait être mal?

InformationsquelleAutor Kelvin | 2009-05-27
  1. 17

    Subversion n'est pas de se plaindre sur le contenu de n'importe quel fichier, mais sur le contenu de la propriété svn:ignore. Une façon de résoudre ce problème est de simplement supprimer la svn:ignore propriété avec svn propdel puis de le recréer.

    Une autre façon qui peut être plus facile si vous avez beaucoup de lignes dans votre svn:ignore:

    1. aller chercher la valeur de la propriété svn:ignore dans un
      fichier temporaire comme ceci:

      svn
      propget svn:ignore . > temp

    2. fixer les fins de ligne dans le temp
      fichier

    3. définir la valeur de la propriété svn:ignore à partir du fichier fixe comme
      ce:

      svn propset svn:ignore -F
      temp .

    • J'ai fini par avoir à utiliser svn propdel et seulement de recréer la propriété. Quand j'ai essayé votre 2ème suggestion (propget > temp), j'ai eu le même message que je recevais avec propedit. Merci!
    • J'ai trouvé un "svn:eol' propriété sur un fichier en particulier, avec la valeur "native". La suppression de cette propriété correction de l'erreur pour moi.
    • retrait de la "svn:eol' propriété a fonctionné pour moi aussi
    InformationsquelleAutor Wim Coenen
  2. 40

    Dans mon cas, svn:eol-style propriété a été définie sur un fichier.
    Et "quelques lignes du fichier ont été séparées par de fins de ligne UNIX (LF caractère), tandis que d'autres ont été séparés par le DOS de style de fin de ligne (CR+LF caractères)". Ici est une autre discussion détaillée de ce problème.

    "Edit"->"EOL Conversion"->"Windows format" dans Notepad++ résolu le problème pour moi.

    • En utilisant TortoiseSVN sur windows avec des menus contextuels de l'explorateur activé, vous pouvez droit-cliquez sur le fichier, puis accédez à "TortoiseSVN" --> "Propriétés". Un dialogue s'affichera. Rechercher un "EOL" de la propriété et de le modifier de la manière appropriée ou tout simplement le supprimer, si vous êtes sûr que EOL n'importe dans votre contexte.
    • Pour moi "Windows format" a été désactivé". Ensuite j'ai converti à unix et puis converti en windows en arrière. Il a travaillé pour moi. @marius solution.
    • Dans mon cas, le svn:eol-style propriété a été définie. Cependant, (en quelque sorte) sa valeur était devenu nativenative (au lieu de simplement native). Peut-être cela peut se produire lorsque l'application d'une svn diff généré patch deux fois (avec svn patch). L'erreur exacte est svn: E135001: Unrecognized line ending style. La modification de la valeur de la propriété de retour à la native résolu le problème. (En ajoutant ce commentaire ici, car c'est le top de Google-résultat de recherche pour l'erreur ci-dessus.)
    InformationsquelleAutor evgeny9
  3. 26

    Dans mon cas, j'ai été dans l'édition de Windows.
    Pour corriger:

    1. Ouvrir le fichier dans Notepad++
    2. Convertir de fin de ligne Unix (menu Edit -> Conversion EOL -> Unix)
    3. Enregistrer
    4. Convertir les fins de ligne de Windows (menu Edit -> Conversion EOL -> Windows)
    5. Enregistrer

    Ce fait.

    • ou: ouvrir wordpad, enregistrer en UTF-8.
    • oui, parfois, cela n'a rien à voir avec la ligne de fin et le client svn en fait juste vous ne pouvez pas lire le fichier pour vérifier les terminaisons
    InformationsquelleAutor Marius Matioc
  4. 8

    De course 

    unix2dos [file]

    via cygwin fixe pour moi.

    • Approximation du premier ordre c'est bien, mais autant que je sache unix2dos ne résout pas seul CRs qui peuvent aussi être en cause. (mais ils sont rares). Dans ce cas, il est préférable de filtrer CRs avec "tr" directement, avant de faire unix2dos
    InformationsquelleAutor gollumullog
  5. 4

    Mon problème était que j'étais arriver dans Visual Studio.NET. Pour le fixer, j'ai copié tout le texte du fichier dans le bloc-notes et enregistrez-le dans le bloc-notes pour "xxx.aspx" ou que ce soit le bon nom de fichier est. Ensuite, dans Visual Studio, j'ai été invité à recharger un fichier modifié, et voila, une boîte de dialogue me demandant si je tiens à normaliser mes fins de ligne. Le problème est résolu.

    • L'amour stupide simple des solutions de ce type. Ne pouvais pas moins de soins sur les raisons de ce qui s'est passé, je voulais juste à aller loin pour un fichier. Il a travaillé pour un projet Eclipse sous Windows.
    • Cela a fonctionné parfaitement pour moi et je n'ai pas de coucher avec svn:ignore. Hourra!
    InformationsquelleAutor Amos Van Horn
  6. 3

    Si elle ne se produit qu'avec un ou deux fichiers, vous pouvez également ouvrir le fichier, copier et coller le contenu dans un nouveau fichier (avec un éditeur de texte), et de l'enregistrer. Ce fichier peut ensuite être ajouté (renommer ou déplacer pour en faire le nom correct).

    InformationsquelleAutor Jan Salvador van der Ven
  7. 1

    Le scénario a vraiment toucher chaque et tous les fichiers texte (en supposant que vous avez dos2unix installé, sinon ce serait pourquoi...)?

    Les autres choses que je peux penser à est de vérifier que tous les fichiers ont leur type mime réglé correctement (vous n'avez pas un fichier binaire qui est en quelque sorte marqué comme un fichier texte enregistré, peut-être?).

    Cela dit, si vous êtes dans l'un des environnements multi-OS je considère que c'est pas une bonne idée de mettre en svn:eol-style à CRLF comme décrit dans le billet de blog ci-dessus si vous êtes le partage et l'édition de texte des fichiers entre les systèmes d'exploitation. Parce que si vous le faites de cette façon, les fichiers semblent OK dans Windows sont remplis avec des caractères de contrôle dans les environnements Unix. Mieux utiliser les "indigènes" comme fin de ligne (EOL style.

    • Timo, je suis tout à fait sûr que le script a touché tous les fichiers texte et je n'ai fait de modifier le script pour "indigènes", avant de l'exécuter. Aussi, je n'ai pas de problèmes lors de la vérification de choses, seulement lors de l'exécution de la propedit de commande. Est-ce que dire quelque chose?
    InformationsquelleAutor Timo Geusch
  8. 1

    J'ai eu cette erreur, mais il a fini par être un fichier manquant la dernière Fin de mensonge incomplètes( dernière ligne).

    Corriger cela en ouvrant le fichier dans VI et en l'enregistrant résolu.

    InformationsquelleAutor Geir Engebakekn
  9. 1

    vi ne m'a pas montré la mauvaise ligne, donc j'ai enlevé la fin de lignes de la section des commentaires, readded (jusqu'à la FIN) et est enregistré le fichier. il a travaillé par la suite.

    REMARQUE: la sauvegarde, vous revprop fichier avant de le tordre. si vous le gazon il, pas de retour en arrière

    InformationsquelleAutor Isaac
  10. 0

    Si vous l'obtenez tout en faisant de la propedit, alors il me semble plus que SVN est de se plaindre sur le format du fichier texte que vous êtes en utilisant pour les propriétés de!

    Quel système d'exploitation êtes-vous? L'éditeur utilisez-vous pour propedit? Si le propedit commande encore les feux d'un éditeur, je voudrais utiliser cet éditeur pour vérifier les fins de ligne sont là (vi n'cette IIRC).

    InformationsquelleAutor ShiDoiSi
  11. 0

    Cela m'a dérangé pour si longtemps, travailler un un multi-système d'équipe avec SVN.
    J'ai fait cette application utile, qui permet de naviguer d'un dossier avec des sous-dossiers de recherche pour les fichiers texte et convertit tous les UNIX EOL à DOS en fin de vie.
    C'est une application AIR, fonctionne sur Windows et Mac.
    espérons que cela aide

    http://www.pippoflash.com/index.php/2012/06/11/svn-error-inconsistent-line-ending-style-nightmare-solved-download-app/

    Filippo

    InformationsquelleAutor PippoApps.com
  12. 0

    Pour mac osx, j'ai eu cette erreur sur un fichier a convertir en utilisant dos2mac et puis mac2unix. Une fois que j'ai fait ce qu'il a fixé la question pour les fins de ligne de se plaindre.

    InformationsquelleAutor Ray Hunter
  13. 0

    Le problème s'est produit pour moi après quelques modifications dans plusieurs fichiers texte a été faite de telle façon que seul \n ont été ajoutés pour séparer certaines lignes, alors que normalement \r\n mettre fin à chaque ligne. Donc, la solution a été d'utiliser Notepad++ pour
    trouver ([^\r])\n
    et de le remplacer avec $1\r\n.
    De cette façon, les caractères de fin de ligne étaient compatibles partout.

    InformationsquelleAutor Bizmarck
  14. 0

    De toujours convertir Windows à des fins de ligne UNIX à l'aide de perl(1):

    perl -p -i.bak -e 's#\r\n#\n#go' my-file.txt

    Pour convertir à partir d'UNIX vers Windows:

    perl -p -i.bak -e 's#\n#\r\n#go' my-file.txt
    InformationsquelleAutor Sean
  15. 0

    J'ai eu le même problème lors de l'exécution de javadoc par l'intermédiaire d'une tâche ant sur une machine Windows.

    Je l'ai corrigé en ajoutant <fixcrlf srcdir="${dir.javadoc}" eol="dos"/> ci-dessous la javadoc tâche ant.

    InformationsquelleAutor Franck de Bruijn
  16. 0

    J'ai eu le même problème dans une archive qui fonctionnait bien avant. Dans notepad++, j'ai choisi de les convertir au format UTF-8. Cela a fonctionné pour moi.

    InformationsquelleAutor Douglas
  17. 0

    J'ai eu le même message d'erreur lorsque vous essayez de svn propset eol-style:native un fichier PHP dans emacs, donc j'espère que cela va aider quelqu'un qui est atteint de cette question.

    J'ai eu quelque chose comme ce qui suit:

    str_replace('</li>^M<br>', '</li>', $text);

    Où ^M est un caractère unique (caret échapper pour un retour chariot).

    La solution était de changer cette ligne jusqu'à l'équivalent:

    str_replace("</li>\r<br>", '</li>', $text);

    Notez les guillemets au lieu de guillemets simples!

    InformationsquelleAutor EoghanM
  18. 0

    Dans mon cas, l'erreur s'est produite parce que le fichier a l'encodage "UCS-2 LE BOM". Les fichiers à la norme ANSI étaient ok. J'ai vérifié les fins de ligne, dans tous les fichiers qu'ils étaient corrects.
    Il semble que (au moins dans ma version SVN) de large char fichiers ne sont parfois pas reconnus correctement.

    La solution la plus simple consiste à supprimer le "svn:eol-style" de la propriété.

    InformationsquelleAutor David Gausmann
  19. 0

    Dans NetBeans, vous pouvez utiliser le bouton "Afficher et modifier les fins de ligne" plugin.

    Après l'installation et le redémarrage de NetBeans, le style de fin de ligne est affiché sur le côté droit de la barre d'état. Vous pouvez cliquer dessus et sélectionner la fin que vous voulez à convertir le fichier.

    Comment dois-je Fixer “svn: l'incohérence de fin de ligne de style”?

    InformationsquelleAutor Jasper de Vries
  20. 0

    Comme "Marius Matioc" évoquée ci-dessus, serait rapide et facile à fixer
    1.Ouvrir le fichier dans Notepad++
    2.Menu edition -> Conversion EOL -> Unix
    3.Enregistrer
    4.Menu edition -> Conversion EOL -> Windows
    5.Enregistrer

    InformationsquelleAutor Ramakrishna Talla