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 <[EMAIL PROTECTED]> Cine7.Net - Milcis.Net - ProgramPlay.Org Jabber: [EMAIL PROTECTED] - ICQ: 48895760 _______________________________________________ gull mailing list [EMAIL PROTECTED] http://lists.alphanet.ch/mailman/listinfo/gull
