Re: svn diff bizarre

In article <87o87m5fyj.fsf@universite-de-strasbourg.fr.invalid>,
 Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> wrote:

Thomas <fantome.forums.tDeContes@free.fr.invalid> writes:
 

j'ai un comportement bizarre de `svn diff` :
>
je vous propose d'essayer ceci :
(évidement les lignes commencent par $)
>
$ svn co
svn://svn.savannah.nongnu.org/rapid/branches/gtkada-2.24/examples/drop_do
wn <où-vous-voulez>/test
$ cd <où-vous-voulez>
$ svn di test/
$ cat test/drop_down.gui
$ rm test/drop_down.gui
$ pico test/drop_down.gui
<copier-coller de la sortie du cat>
$ svn di test/
>
et là, svn diff, au lieu d'indiquer la ligne supplémentaire, il indique
un remplacement complet !

 
Je parierais sur des fins de lignes converties soit par cat (par le
terminal) soit par pico.

bien vu :-)

Ensuite od ou hd devrait confirmer.

hd c'est un raccourci pour hexdump ?
(bizarre c'est pas un alias)

mais ça va, mon éditeur de texte m'indique bien que les fins de ligne
sont en CRLF,
je n'y avais juste jamais fait attention :-)


alors ça m'étonne parce que j'avais compris que svn savait traiter les
fins de ligne correctement et automatiquement.
mais en fait je crois que j'avais mal compris :

https://svnbook.red-bean.com/fr/1.8/svn.advanced.props.file-portability.h
tml#svn.advanced.props.special.eol-style ( https://urlpetite.fr/2zf )


si je comprend bien maintenant, il faut définir la propriété
svn:eol-style, sinon ça traite les fichiers texte simplement comme les
fichiers binaires ...
dommage qu'il n'ait pas été décidé de mettre le comportement de 'native'
par défaut :-(


1)
ensuite, il faut que je définisse la propriété svn:auto-props, pour tous
les nouveaux fichiers à venir :

quelles sont les bonnes pratiques dans ce domaine ?

est-ce que c'est recommandé de définir cette propriété à la racine de
chaque nouveau projet, pour avoir les bons traitements automatiques des
le début ?

est-ce que c'est une amélioration qu'on peut demander à l'administrateur
du dépôt, ou est-ce que c'est obligatoirement à chaque gestionnaire de
projet de le faire ?

est-ce que c'est bien de mettre
* = svn:eol-style=native
et de laisser svn faire le tri pour ne pas l'appliquer aux fichiers
binaires,
ou est-ce que c'est très risqué, et il vaut bcp mieux faire l'inventaire
des extensions dont on se sert ?

pendant que j'y suis, il me semble bien d'en profiter pour définir les
types MIME.
(à moins que dans svn il n'y ait pas d'autre utilité réelle que pour le
navigateur ?)

y a-t-il qqpart une liste de types MIME avec notamment les images les
plus courantes, que je puisse recopier là sans avoir besoin de chercher
le bon type MIME pour chaque image ?


2)
et ensuite, il faut que j'applique tout ça aux fichiers existants :

y a-t-il un moyen d'appliquer automatiquement la prescription de
svn:auto-props à tous les fichiers existants, en suivant les motifs de
noms de fichiers ?


pour finir, il y a qqch de très très casse-pied par rapport à mon pb :
on dirait que des que je vais appliquer svn:eol-style=native à un
fichier existant qui est en CRLF, ça va indiquer que le fichier entier a
changé !
probablement parce qu'avec svn:eol-style=native c'est enregistré dans le
dépôt sous forme de LF
(du coup, ça n'est pas "tout à fait transparent pour l'utilisateur" !)

je peux faire un commit exprès pour ça, sans aucun autre changement,
mais ça va rester un gros pb quand plus tard je souhaiterai faire des
`svn diff` qui seront à cheval autour de cette révision ...

existe-t-il un moyen de contourner ce pb ?

--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/