Deutsch   English   Français   Italiano  
<fantome.forums.tDeContes-1AB1D7.18492419102021@news.free.fr>

View for Bookmarking (what is this?)
Look up another Usenet article

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 <fantome.forums.tDeContes@free.fr.invalid>
Newsgroups: fr.comp.os.unix
Mail-Copies-To: nobody
Subject: Re: svn diff bizarre
References: <fantome.forums.tDeContes-3DCE79.19581418102021@news.free.fr> <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: <fantome.forums.tDeContes-1AB1D7.18492419102021@news.free.fr>
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 <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/