2011-08-16 6 views
1

Nous développons principalement notre application PHP sur un environnement Windows et avons stocké nos fichiers source texte dans PC/ANSI.Quel codage utiliser pour le développement multiplateforme (PC, Mac, Linux)?

Cependant, maintenant, un développeur se joint à nous qui utilise une plate-forme Mac et nous rencontrons des problèmes de création de «patches» sur sa machine. Quand il fait des changements et fait:

svn diff > patchfile.patch 

il génère un fichier de patch qui indique que chaque ligne du fichier de code source a été modifié (ce qui nest pas le cas évidemment).

J'ai essayé d'enregistrer un fichier ANSI test:

PC/UTF-8 (using UTFCast Express which I writes the BOM by default) 
PC/UTF-8 (using Notepad++ "Encoding > Convert to UTF-8" - which writes the BOM) 

En plus:

PC/UTF-8 (using Notepad++ "Encoding > Convert to UTF-8 without BOM") 
PC/UTF-8 (using Notepad++ "Encoding > Encode in UTF-8 without BOM") 

Pour tous ces cas, chaque fois qu'il fait un changement et fait un diff svn> rustine. patch, il affiche toutes les lignes comme si toutes les lignes avaient été changées!

[nous avons essayé de faire « svn diff -x -p> patchfile.patch » pour les 3 derniers aussi bien - pas de différence]

Soit dit en passant, les fichiers générés avec les deux dernières options continuent d'apparaître comme ANSI sur ma machine PC. Les deux ne semblent pas du tout modifier le fichier et faire un 'fc' (comparaison de fichiers) à partir de l'invite DOS ne révèle aucune différence.

Quel encodage dois-je utiliser pour le développement multiplateforme?

Répondre

5

Pas un problème de codage de caractères, mais un problème de fin de ligne. Windows utilise CR-LF (13/10), les Mac utilisent maintenant (style unix) LF seulement (10).

Définissez la propriété subversion svn: eol-style = natif sur les fichiers appropriés pour le faire fonctionner correctement.

+0

Salut davmac - est-ce défini sur le côté client SVN ou sur le serveur? comment puis-je le définir pour l'ensemble du référentiel SVN pour utiliser l'encodage «natif» pour tout? – siliconpi

+0

Vous définissez la propriété sur le client, puis la validez dans le référentiel. Voir http://subversion.apache.org/faq.html#auto-props et http://svnbook.red-bean.com/fr/1.6/svn.advanced.props.html (en particulier sous "Réglage automatique de la propriété") – davmac

0

Windows utilise la fin de ligne "\ r \ n" (retour chariot/retour chariot).

OS/X utilise des caractères "\ n" unix.

L'OS9 précédent utilisait "\ r". Je ne suis pas sûr pourquoi vous voudriez l'encodage de caractères UTF-8 pour le code source à moins que vous ayez fait cela tout le temps pour tous vos dossiers, particulièrement si vous êtes tous les haut-parleurs de langue anglaise pour le projet.

Votre mac dev devrait essayer de configurer son éditeur de manière à utiliser les fins de ligne PC pour être compatible avec le reste d'entre vous. Souvent, les éditeurs détectent les bonnes fins de ligne et utilisent les bonnes pour les fichiers existants, mais pour les fichiers créés, ils peuvent être configurés pour utiliser leur système d'exploitation par défaut.

Vous pouvez expérimenter avec flip qui est un outil de ligne de commande multiplateforme qui convertira les caractères de fin de ligne d'un os à un autre.

+0

Vous pouvez également configurer svn pour exécuter flip dans un hook post-commit si les mauvaises fins de ligne ont été trouvées, mais vous devez faire attention à ne pas autoriser l'exécution de ceci binaires car il pourrait les corrompre. – gview

+0

nous aurons aussi des jeux de caractères spéciaux 'étendus' utilisés dans notre code source. – siliconpi

Questions connexes