Path: ...!news.mixmin.net!proxad.net!feeder1-2.proxad.net!212.27.60.64.MISMATCH!cleanfeed3-b.proxad.net!nnrp1-1.free.fr!not-for-mail From: Thomas Newsgroups: fr.comp.os.unix Mail-Copies-To: nobody Subject: Re: svn diff bizarre References: <87o87m5fyj.fsf@universite-de-strasbourg.fr.invalid> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit User-Agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X) Date: Tue, 19 Oct 2021 18:49:24 +0200 Message-ID: Lines: 110 Organization: Guest of ProXad - France NNTP-Posting-Date: 19 Oct 2021 18:49:25 CEST NNTP-Posting-Host: 91.175.52.121 X-Trace: 1634662165 news-4.free.fr 4992 91.175.52.121:12376 X-Complaints-To: abuse@proxad.net Bytes: 4839 In article <87o87m5fyj.fsf@universite-de-strasbourg.fr.invalid>, Alain Ketterlin wrote: > Thomas 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 /test > > $ cd > > $ svn di test/ > > $ cat test/drop_down.gui > > $ rm test/drop_down.gui > > $ pico test/drop_down.gui > > > > $ 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/