Pourquoi est-patch de rejet de mon patch-fichier sur un SVN copie de travail?

J'ai un patchfile comme ceci:

Index: dir/file.xml
===================================================================
--- dir/file.xml    (revision 178)
+++ dir/file.xml    (working copy)
@@ -7,7 +7,7 @@
    <markup>
-   <markup />
+   <markup></markup>
    <markup>
    <markup>
@@ -20,6 +20,7 @@
    <markup>
    <markup>
+   <tag>
    <markup>

De l'appliquer à la SVN de la copie de travail, j'ai bifurqué à l'aide de:

$ svn copy -r 178 trunk/component/dir branches/mybranch

Ensuite, j'ai essayé

$ cd branches/mybranch
$ ls -R
./dir:
file.xml
$ patch -p0 -i ~/patchfile.patch

mais SVN de sortie est

(Stripping trailing CRs from patch.)
patching file dir/file.xml
Hunk #1 FAILED at 7.
Hunk #2 FAILED at 20.
2 out of 2 hunks FAILED -- saving rejects to file dir/file.xml.rej

pour chaque fichier?

Ce qui pourrait causer des SVN pour rejeter le patch? Je suis sur une machine UNIX, mais patch et référentiel avoir Windows ligne terminaisons...

Merci pour l'aide!

OriginalL'auteur Simon | 2011-01-14

  1. 7

    La dos2unix conseil n'était pas mauvais, mais ne résout pas le problème, comme l'a suggéré.

    Ce que j'ai fait réellement patch tous les fichiers:

    $ cd branches/mybranch
$ sudo apt-get install tofrodos
$ fromdos ~/patchfile.patch
$ fromdos */*
$ patch -p0 -i ~/patchfile.patch
$ todos */*

    Donc, fondamentalement, patch semble avoir un problème de manipulation CR/LF lignes sous Unix. La conversion à LF, puis de patch et de le convertir en arrière après la mise à jour aidé.

    Crédits à Stefan.

    Ceci est également résolu mon problème, merci. En effet, il semble que le patch ne gère pas les CRLF bien, même lorsque les deux dans le patch et pour être corrigé les fichiers.
    patch a bien fonctionné pour moi avec CRLF, si les deux patch fichier & pour être corrigé les fichiers de suivre la même ligne de terminaisons (j'.e CRLF/LF)

    OriginalL'auteur Simon

  2. 1

    vous pouvez essayer l'outil dos2unix sur le fichier de correctif. Qui va convertir les fins de ligne.

    A donc. Maintenant, il ne dit pas "(Décapage de fuite CRs de patch.)" plus. Les erreurs sont toujours présentes.
    dos2unix rend l'application de correctifs sur OK. Mais le résultat n'a pas de saut de ligne. Dans mon cas par ex, le fichier contient: catdogcow
    Ce n'est pas le fichier de correctif de ce problème, c'est que les fichiers source

    OriginalL'auteur Stefan

  3. -1

    Modifié:
    Donc, nous avons établi que patch n'est pas un outil SVN. SVN n'ont pas d'influence directe sur ce, à moins qu'il a créé le fichier de correctif de manière incorrecte.

    Êtes-vous sûr que le patchfile a été créé à partir du tronc? Si oui, votre copie doit être identique à celui que le patch a été basé sur, il devrait donc y avoir aucune raison pour qu'il échoue. La seule conclusion à laquelle je pense est qu'il ya quelque chose de mal avec le fichier de correctif; il ne correspond pas à votre fichier.

    Confirmer que dir/file.xml dans votre copie de travail contient réellement

      <markup>
  <markup />
  <markup>
  <markup>

    commençant à la ligne 7. (Je suis en supposant que le code dans votre question, c'est juste une copie modifiée de toute façon, car il devrait être de 7 lignes il y, pas 4.) Qui est, le contenu du fichier de correspondance du contenu du patch? Payer une attention particulière à l'espacement et les fins de ligne. Si c'est le cas, il devrait y avoir aucune raison de patch serait un échec que hunk.

    Merci, Zac. Mais je sais que le patch n'est pas une partie de la subversion. Après quelques tentatives, je suis aussi tombée sur ce dossier en question. J'aurais dit, que dir est en fait dans ma branche. Essayer patch -p[N] n'a retourné une erreur de ce type file not found ou similaire. Jetez un oeil à mes modifications. Merci!

    OriginalL'auteur Zac Thompson