[gull] [COURS 25] Réponses aux questions

[Sebastien Cevey]

Voila les réponses aux questions posées pendant le cours.  Si vous en
avez d'autres, posez les sur la liste ;-)


> Avec Subversion, est-ce que les pristine copies (copies intactes de
> la dernière version mise à jour) sont optionnelles ?

Non, ou du moins pas encore. Les working copies font donc
effectivement le double de taille de leur contenu. Il me semblait
avoir lu que qqn proposait de compresser les pristine files, mais cela
réduirait forcément la vitesse de traitement de ces fichiers.

Le livre [1] résume bien le problème :

   Some attention is being given to making the presence of the
   "text-base" an option. Ironically though, it is as your versioned
   files' sizes get larger that the existence of the "text-base"
   becomes more crucial --- who wants to transmit a huge file across a
   network just because they want to commit a tiny change to it?

En effet, les pristine copies permettent notamment de n'envoyer au
repository QUE le diff entre la version pristine et la version
modifiée. Cela peut être un gain significatif dans le cas de gros
fichiers.

Note: CVS n'envoie de diff que dans le sens repository->WC, Subversion
dans les deux sens.


> Avec Subversion, peut-on gérer le mode du fichier ?

Pas directement pour le moment.  J'ai lancé le thread sur la ML et
cela pourrait etre fait après la 1.0.

Quelqu'un a posté [2] un shell wrapper qui permet, en utilisant les
meta-données attachées aux fichiers, de gérer les modes des
fichiers. Je ne l'ai pas essayé, mais je pense qu'il n'y a pas de
raison que cela soit impossible.

Sinon par défaut, Subversion conserve le mode du fichier lors des
updates tant que le fichier subsiste. Mais si le fichier est effacé et
réccupéré par un `svn update` alors le mode est "perdu" (remis au
défaut). Dans le cas d'un nouveau checkout, le mode n'est pas non plus
customizable, c'est celui par défaut.


> Avec Subversion, comment supprimer une révision ou un fichier du
> repository.

Le but d'un VCS est bien évidemment de ne JAMAIS permettre la perte
d'un élément. Mais comme toujours, rien n'est impossible :-)

Avec CVS, il fallait aller bidouiller le repository à la main.

Avec Subversion, c'est un peu la même chose. Il est possible de faire
un dump (svnadmin dump) de la DB, de supprimer les éléments
indésirables du dump (le format est éditable sauf erreur), et de
reloader le contenu dans un nouveau repository qui remplace l'ancien.

Sinon, svnadmin dump permet de donner des bornes inférieures et
supérieures pour le dump.

Mais je crois que la solution "officielle" actuelle, c'est d'utiliser
le programme dédié svndumpfilter qui permet d'exclure des éléments
d'un dump. Je n'ai jamais utilisé cet outil, mais il fait partie de la
distribution subversion et dispose d'une aide en ligne de commande au
moins. Il faut l'essayer ...


> Avec Subversion, peut on faire un `svn cat` sur un fichier binaire ?

Oui.  Par défaut la sortie (binaire) est effectuée sur stdout, qu'il
est facile de rediriger dans un fichier. Le fichier réccupéré est
identique à celui que l'on aurait réccupéré par un checkout habituel.


> Avec Subversion, d'où vient le username (p ex affiché avec
> `svn ls -v`) ?

Cela semble dépendre du protocole utilisé. Voila ce que j'ai compris
de divers messages sur la ML :

Avec ra_dav (par Apache / WebDAV, donc http:// ou https://), l'auteur
est "anonymous" à moins que Apache soit en mesure de communiquer un
username (si une authentification de type htaccess/htpasswd est
effectuée).

Avec ra_local (accès local par file://), il s'agit du username sur la
machine.

Avec ra_svn (serveur svnserve dédié, accédé en local ou par tunnel
SSH), le username est 'anonymous' par défaut, sauf si le serveur est
accédé en tunnel ssh, auquel cas c'est le username de login par ssh
qui est utilisé.


> Avec Subversion, pourquoi la séquence suivante demande-t-elle
> d'utiliser le flag --force ?

wc $ svn add toto
A         toto
wc $ svn rm toto
svn: Attempting restricted operation for modified resource
svn: Use --force to override this restriction
svn: 'toto' has local modifications
wc $

Pour annuler l'addition, il faut utiliser `svn revert`, qui aura pour
effet de retirer le statut "Scheduled for addition" du fichier tout en
laissant le fichier dans le repository.

Avec la commande `svn rm` ci-dessus, le fichier est non-seulement
retiré de la liste des fichiers à ajouter, il est aussi supprimé du
disque dur !

Cette opération étant "dangereuse" et "irréversible", le --force est
requis.


> Idem pour :

wc $ svn st
wc $ echo x >> empty.txt 
wc $ svn mv empty.txt full.txt
svn: Attempting restricted operation for modified resource
svn: Use --force to override this restriction
svn: Pass --force to override this restriction
svn: 'empty.txt' has local modifications
wc $ svn mv --force empty.txt full.txt
A         full.txt
D         empty.txt
wc $ svn st
A  +   full.txt
D      empty.txt
wc $

Ici je n'ai pas de réponse officielle, mais je me demande si ce n'est
pas du au fait que :

wc $ svn help move | grep -i note
  NOTE:  this command is equivalent to a 'copy' and 'delete'.
wc $

Peut-être est-ce dû au fait que l'on ne peut pas vraiment faire un
`svn revert` qui remet la WC dans le status précédent (ce qui serait
possible si on fait un commit entre le `echo` et le `svn mv`).



[1] http://svnbook.red-bean.com/
[2] http://www.contactor.se/~dast/svnusers/archive-2003-12/0319.shtml

-- 
Sebastien Cevey <seb at cine7.net>
Cine7.Net  -  Milcis.Net  -  ProgramPlay.Org
Jabber: theefer at albus.homelinux.net - ICQ: 48895760