Le jeu 25/07/2002 à 10:06, Sébastien Bonnegent a écrit :
> Branko ÄŒibej wrote:
> [...]
> BÄ> Personally I have no reservations against putting this into the
> BÄ> repository. I think it would be useful. I wish somebody could review
> BÄ> your translation, though. While I can read it, I'm not competent to
> BÄ> review it.
> BÄ>
> BÄ> Anyone?
>
> I can read it, I discover subversion since a week and I
> find it not bad :-)
>
> In the same time, it will be usefull for me to know
> more about it.
>
> Where can I find this french translation ?
switch to french.
Cool.
Le patch est join au fichier.
Le patch installe la doc française et anglaise bien sûr.
Sinon, la doc est en ligne ici : http://feliciano.matias.free.fr/svn/
pour un gros fichier c'est :
http://feliciano.matias.free.fr/svn/svn-handbook-french.html
J'ai traduit "commit" par remontée.
Pour "log message" j'ai utilisé "Description de modification".
J'aimerai un avis sur ces traductions et ... tout le reste.
NB: j'ai tendance à faire pas mal de faute d'orthographe. Je n'ai pas
fait de relecture attentive. C'est un travail que je ferai lorsque
Subversion sera proche de la version 1.0.
La traduction est basée sur la révision 2610. Il y a donc des trucs pas
à jour. Entre autre l'option '-d' n'est plus nécessaire avec "svn co".
>
> seß - sinad ( a french man :-)
> --
> GPG uid: 0xCB92591D ICQ: 60143970
> LINUX - because life is too short to reboot !
Index: ./Makefile.in
===================================================================
--- ./Makefile.in
+++ ./Makefile.in Tue Jul 23 05:27:55 2002
@@ -7,7 +7,7 @@
SVN_RA_LIB_DEPS = @SVN_RA_LIB_DEPS@
SVN_RA_LIB_LINK = @SVN_RA_LIB_LINK@
-DOC_DIRS = doc/programmer/design doc/handbook
+DOC_DIRS = doc/programmer/design doc/handbook doc/handbook/french
EXTERNAL_PROJECT_DIRS = @SVN_SUBDIRS@
@@ -160,18 +160,18 @@
doc: doc-info doc-txt doc-html
-doc-info: doc/programmer/design/svn-design.info doc/handbook/svn-handbook.info
-doc-dvi: doc/programmer/design/svn-design.dvi doc/handbook/svn-handbook.dvi
-doc-txt: doc/programmer/design/svn-design.txt doc/handbook/svn-handbook.txt
-doc-html: doc/programmer/design/svn-design.html doc/handbook/svn-handbook.html
-doc-ps: doc/programmer/design/svn-design.ps doc/handbook/svn-handbook.ps
-doc-pdf: doc/programmer/design/svn-design.pdf doc/handbook/svn-handbook.pdf
+doc-info: doc/programmer/design/svn-design.info doc/handbook/svn-handbook.info doc/handbook/french/svn-handbook-french.info
+doc-dvi: doc/programmer/design/svn-design.dvi doc/handbook/svn-handbook.dvi doc/handbook/french/svn-handbook-french.dvi
+doc-txt: doc/programmer/design/svn-design.txt doc/handbook/svn-handbook.txt doc/handbook/french/svn-handbook-french.txt
+doc-html: doc/programmer/design/svn-design.html doc/handbook/svn-handbook.html doc/handbook/french/svn-handbook-french.html
+doc-ps: doc/programmer/design/svn-design.ps doc/handbook/svn-handbook.ps doc/handbook/french/svn-handbook-french.ps
+doc-pdf: doc/programmer/design/svn-design.pdf doc/handbook/svn-handbook.pdf doc/handbook/french/svn-handbook-french.pdf
doc-clean:
for d in $(DOC_DIRS); \
do \
(cd $$d; \
- rm -f *.info *.info-1 *.info-2 *.info-3 \
+ rm -f *.info *.info-[1-9] \
*.aux *.cp *.fn *.ky *.log *.pg *.toc \
*.tp *.vr \
*.dvi *.txt *.html *.ps *.pdf); \
Property changes on: ./ac-helpers
___________________________________________________________________
Name: svn:ignore
- config.guess
config.sub
ltconfig
ltmain.sh
libtool.m4
check-diff-output.tmp
*.o
*~
.*~
+ config.guess
config.sub
ltconfig
ltmain.sh
libtool.m4
check-diff-output.tmp
*.o
*~
.*~
Index: ./build.conf
===================================================================
--- ./build.conf
+++ ./build.conf Tue Jul 23 05:27:55 2002
@@ -80,6 +80,11 @@
doc/programmer/design/svn-design.info-1
doc/programmer/design/svn-design.info-2
doc/programmer/design/svn-design.info-3
+ doc/handbook/french/svn-handbook-french.info
+ doc/handbook/french/svn-handbook-french.info-1
+ doc/handbook/french/svn-handbook-french.info-2
+ doc/handbook/french/svn-handbook-french.info-3
+ doc/handbook/french/svn-handbook-french.info-4
# The subversion repository administration tool
[svnadmin]
Property changes on: ./doc/handbook/french
___________________________________________________________________
Name: svn:ignore
+ *.html
*.txt
*.info
*.info*
*.ps
*.pdf
*.aux
*.cp
*.dvi
*.fn
*.ky
*.log
*.pg
*.toc
*.tp
*.vr
svn-handbook-french
Index: ./doc/handbook/french/getting_started.texi
===================================================================
--- ./doc/handbook/french/getting_started.texi
+++ ./doc/handbook/french/getting_started.texi Tue Jul 23 05:27:55 2002
@@ -0,0 +1,834 @@
+@node Débuter avec Subversion
+@chapter Débuter avec Subversion
+
+Bien débuter avec Subversion.
+
+@menu
+* Introduction:: Historique et fonctionnalités.
+* Architecture:: Organisation de Subversion.
+* Installation:: Obtenir Subversion.
+* Concepts:: Concepts et première utilisation.
+@end menu
+
+
+@c ------------------------------------------------------------------
+@node Introduction
+@section Introduction
+
+@subsection Système de contrôle de version
+
+Subversion est logiciel libre (open-source) @dfn{système de contrôle de version}.
+
+C'est-à-dire que Subversion gère les fichiers dans le temps. Les fichiers
+sont déposés dans un @dfn{dépôt} central. Le dépôt peut-être vu comme un
+serveur de fichier classique, si ce n'est qu'il conserve tous les
+modifications réalisées à vos fichiers. Ceci vous permet de récuperer
+d'anciennes versions de vos fichiers, ou de consulter l'historique des
+modifications de vos fichiers.
+
+Certaines systèmes de contrôle de version sont aussi des systèmes
+@dfn{gestion de configuration}. Ces systèmes sont spécifiquement conçus
+pour gérer des arborescences de code source, et ont des fonctionnalités
+qui sont spécifiques au développement de logiciel (comme la compréhension
+de language de programmation). Subversion ne fait pas parti de ces types
+de systèmes; Subversion est un système général qui peut-être utilisé pour
+gérer @emph{tout} type d'ensemble de fichiers. (Il reste néanmoins
+parfaitement adapdé pour gerer du code source.)
+
+
+@subsection Historique
+
+Subversion se veut être le successeur de CVS (@url{http://www.cvshome.org}).
+
+Lors de l'écriture de Subversion, CVS était le standard des systèmes de
+contrôle de version libre utilisé par la communauté open-source. C'est un
+excellent produit, sérieux et avec une grande réputation de faibilité.
+Il a été conçu pour être parfaitement adapté au développement
+open-source. Cependant, il a aussi quelques défauts qui sont
+difficilement corrigables.
+
+Les concepteurs originels de Subversion se sont concentrés sur quelques
+objectifs simples: ils ont décidé que Subversion sera un remplaçant
+fonctionnel de CVS. Subversion fera tout ce que CVS fait -- ceci en
+conservant le même model de développement et en corrigant les défauts
+les plus évidents. Les utilisateurs actuels de CVS sont la la cible
+prévilégiée de Subversion. Tout utilisateur de CVS doit être capable
+d'utiliser Subversion après un petit effort.
+
+Collabnet (@url{http://www.collab.net}) a fourni les moyens initiaux
+nécessaires en 2000 pour débuter le travail de développement. Cette
+initiative est devenue un important projet open-source poussé par la
+communauté des développeurs de logiciel libre.
+
+
+@subsection Fonctionnalités
+
+Quelles fonctionnalités de Subverion le rend meilleur que CVS? Voici une
+petit liste qui vous mettra en appétit:
+
+@itemize @bullet
+
+@item
+@b{Versionnement des répertoires} Le dépôt de Subversion n'utilise pas les
+fichiers RCS contrairement à CVS; au-lieu de celà, il implémente un
+système de fichier versionné 'virtuel' qui trace les arborescences dans le
+temps. Les fichiers @emph{et} les répertoires sont versionnés. Ainsi, on
+trouve de réels commands 'move' (déplacer) et 'copy' (copier) du coté
+client.
+
+@item
+@b{Requête de changement atonic} Une requête de changement du dépôt
+(central) est totalement réalisée ou pas du tout. Elle n'est jamais
+partiellement réalisée.
+
+@item
+@b{Interface réseau évoluée} Le serveur réseau de Subversion est Apache,
+le client et le serveur communiquent ensemble en utilisant le protocole
+WebDav. (voir @ref{Architecture})
+
+@item
+@b{Accès réseau optimisé} Un algorithme de detection de différences
+binaire est utilisé pour stocker et transmettre les écarts dans les deux
+sens, que ce soit un fichier texte ou de type binaire.
+
+@item
+@b{Méta-donnée} Chaque fichier ou répertoire a un invisible tableau qui
+lui est attaché. Vous pouvez stocker n'importe quelles paire clée/valeur
+que vous voulez: propriétaire, permissions, icône, type mime, notes
+personnel, etc. Cette fonctionnalité donnée à l'utilisateur est à usage
+générale. Les propriétés sont versionnées dans le temps exactement comme
+le contenu des fichiers.
+
+@item
+@b{Capacité d'adaptation} Subversion ne traine pas de 'boulet'
+historiques; c'est principalement un ensemble de librairies C partagées
+avec des interfaces bien conçues. Ceci rend Subversion facilement
+maintenable et utilisable par d'autres programmes ou languages.
+@end itemize
+
+
+@c ------------------------------------------------------------------
+@node Architecture
+@section Architecture
+
+
+Subversion a une conception modulaire; il est basé sur un ensemble de
+librairie C. Chaque librairie a un objectif précis et une interface bien
+conçue.
+
+Si vous n'est pas interessé par les rouages internes de Subversion, sauté
+cette partie et allé à @ref{Installation} et @ref{Concepts}.
+
+Voici un diagramme des différentes couches de Subversion. Le flux du
+programme débute en haut du diagramme (à l'initiative du l'utilisateur)
+et continue vers le bas.
+
+@c ### Insert Fitz's nicer TIFF graphic here? Perhaps use that
+@c graphic for dvi or html output, but use the ASCII diagram for info
+@c output? We'll need texinfo conditionals for that.
+
+@example
+@group
+ +---------------------+
+ | ligne de commande |
+ | interface graphique |
+ | programme client |
+ +----------+---------------------+---------+ <=== Interface client
+ | Librairie client |
+ | |
+ | +---+ |
+ | | | |
+ +-------+---------+ +--------------+--+----------+ <=== Interface réseau
+ | Copie de travail| | Accès distant| | Accès |
+ | lib de gestion | | du dépôt | | local |
+ +-----------------+ +--------------+ | du dépôt |
+ | neon | | |
+ +--------------+ | |
+ ^ | |
+ / | |
+ DAV / | |
+ / | |
+ v | |
+ +---------+ | |
+ | | | |
+ | Apache | | |
+ | | | |
+ +---------+ | |
+ | mod_DAV | | |
+ +-------------+ | |
+ | mod_DAV_SVN | | |
+ +----------+-------------+--------------+----------+ <=== Interface du système de fichier
+ | |
+ | Système de fichier de Subversion |
+ | |
+ +--------------------------------------------------+
+
+@end group
+@end example
+
+
+@subsection Système de fichier
+
+Le système de fichier de Subversion n'est pas un système de fichier au
+niveau noyau qu'une personne peut installer sur un système d'exploitation
+(comme Linux ext2 fs). Au-lieu de celà, il désigne le concept de dépôt de
+Subversion. Le dépôt s'appuit sur une base de données -- actuellement
+Berkeley DB -- qui est un ensemble de fichiers .db . Cependant, une seule
+librairie accède à ces fichiers et exporte une API (interface) C qui
+simule un système de fichier -- plus spécifiquement un système de
+fichier versionné.
+
+Ceci signifie qu'écrire un programme qui accède au dépôt est comme écrire
+un programme qui utilise une autre API de système de fichier: vous pouvez
+ouvrir en lecture ou écriture des fichiers et des répertoires de la même
+façon.
+
+L'utilisation d'un moteur de base de données fournie d'autres
+fonctionnalités appréciables dont Subversion a besoin: intégrité des
+données, écriture atonique, restauration dans un état cohérent, et
+sauvegarde à chaud.
+
+
+@subsection Interface réseau
+
+Subversion est tout entier marqué par Apache. En son coeur, le client
+Subversion utilise la librairie d'exécution portable d'Apache (Apache
+Portable Runtime : APR). Ceci permet au client Subversion de se compiler
+et s'exécuter partout où le verseur httpd d'Apache le fait --
+actuellement, la liste inclue la plupart des Unix, Win32, BeOS, OS/2,
+Mac OS X, et peut-être Netware.
+
+Cependant, Subversion ne dépend pas que de APR -- le "serveur" Subversion
+est httpd d'Apache lui-même. httpd d'Apache est éprouvé depuis longtemps,
+c'est un serveur open-source extensible qui est prêt pour des utilisations
+sérieuses. Il peut supporter de fortes charges réseau, fonctionne sur de
+nombreuses plateformes, et est accessible via des pares-feu / proxy
+(firewalls). Il peut utiliser de nombreux différents protocoles
+d'authentification et supporte "network pipelining and caching" (comment
+traduit çà ?). En utilisant Apache comme serveur, Subversion profite de
+tous ces caractéristiques pour un coût nul.
+
+WebDAV est le protocole réseau utilisé par Subversion. DAV (Distributed
+Authoring and Versioning : système de publication et de versionnement
+distribué) mériterait un livre entier à lui seul (voir www.webdav.org) --
+pour résumer, c'est une extension du protocole HTTP qui permet de
+lire/ecrire et le versionnement de fichiers via le web. Le project
+Subversion espère une amélioration du support de ce protocol: tous les
+derniers gestionnaires de fichier de win32, MacOS, et GNOME support déjà
+ce protocole. Interopérabilité deviendra enfin petit à petit une réalité.
+(Cette partie est plustôt mal traduite !).
+
+Pour les utilisateurs qui souhaitent seulement accéder à un dépôt
+Subversion sur leur disque local, le client peut aussi le faire; le réseau
+n'est pas nécessaire. La couche RA ("Repository Access" qui permet
+d'accéder au dépôt) est une API abstraite implémentée par la librairie RA
+de DAV (accès réseau) et d'accès local. C'est le bénéfice d'écrire un
+système de gestion de version orienté "librairie": envie d'écrire un
+nouveau protocole réseau pour Subversion? Il suffit d'écritre une nouvelle
+librairie qui implément l'API RA.
+
+@subsection Librairies clientes
+
+Du côté client, la librairie chargée de la "copie de travail" de
+Subversion gère des informations administratives dans le sous-répertoire
+spécial .svn dont l'objectif est similaire au répertoire d'administration
+de CVS qu'on trouve dans la copie de travail de CVS.
+
+Un coup d'oeil à l'intérieur d'un répertoire .svn typique en montre un
+peu plus cependant. Le fichier 'entries' contient de l'XML qui décrit
+l'état actuel du répertoire de copie de travail (et qui sert
+essentiellement à la même chose que les fichiers Entries, Root de CVS,
+"and Repository files combined" (comme traduire ?) ). Mais d'autres
+élements (et que l'on ne trouve pas dans CVS) fournissent un lieu de
+stockage pour les propriétés versionnées (les méta-données cités dans
+"Fonctionnalités" au-dessus) et un cache privé de la version du dépôt
+(C'est-à-dire sans les modifications locales à la copie de travail). Ce
+dernier point permet de connaitre les modifications locales -- et de les
+annuler -- @emph{sans} demander d'accès réseau. Les données
+d'authentification sont également stockées dans .svn/, au-lieu d'un seule
+fichier du type .cvspass.
+
+La librarie "client" de Subversion a la plus large responsabilité; sa
+tâche est de combiner les fonctionnalités de la librairie gérant la copie
+de travail avec la librarie d'accès au dépôt, et ainsi de fournir une API
+de haut-niveau pour toute application qui veux réaliser des actions
+générales de control de révision. @footnote{Par exemple: la routine C
+'svn_client_checkout()' prend une URL en paramètre. Il passe cette URL
+à la librairie d'accès au dépôt et lance une session authentifiée avec
+le dépôt. Puis il demande au dépôt une certaine arborescence, et envoie
+cette arborescence à la librairie qui gére la copie de travail, qui
+ensuite écrit une copie de travail complète sur le disque (répertoires
+.svn et l'arborescence).}
+
+La librairie cliente est conçue pour être utilisée par n'importe quelle
+application. Alors que les codes source de Subversion inclut un client en
+ligne de command standard, il doit être très facile d'écrire des clients
+graphiques au-dessus de la librairie cliente.
+
+
+@c ------------------------------------------------------------------
+@node Installation
+@section Installation
+
+### Somebody please write this. It should describe how to fetch various
+binary packages of Subversion for different platforms. Maybe this
+will flesh out once RPMs, .debs, and BSD ports are widely available
+from standard locations?
+
+Pour construire Subversion depuis le code source,
+@xref{Compilation et installation}.
+
+
+@c ------------------------------------------------------------------
+@node Concepts
+@section Concepts
+
+
+Si vous êtes actuellement un utilisateur de CVS, alors la première
+section, @ref{Comment développer avec Subversion}, doit vous être
+familière. Vous devriez juste le parcourir rapidement, il n'y a rien de
+spécial dans la définition de "Révision" dans la seconde sous-section. A
+certain endroit, vous devriez probablement lire aussi l'appendice qui
+décrit les différences fondamentales entre CVS et SVN
+(@xref{SVN pour les utilisateurs de CVS}.).
+
+
+@menu
+* Comment développer avec Subversion::
+* Utilisation de Subversion::
+@end menu
+
+@node Comment développer avec Subversion
+@subsection Comment développer avec Subversion
+
+@menu
+* Répertoire de travail et dépôt::
+* Transactions et numéro de révision::
+* Etat du répertoire de travail par rapport au dépôt::
+* Subversion ne verrouille pas les fichiers::
+@end menu
+
+@node Répertoire de travail et dépôt
+@subsubsection Répertoire de travail et dépôt
+
+Imaginons que vous utilisez Subverion pour gérer un project de logiciel.
+Il y a deux choses avec lesquelles vous allez être en intéraction: votre
+répertoire de travail et le dépôt.
+
+Votre @dfn{répertoire de travail} est une arborescence de répertoire
+ordinaire sur votre système et contenant les sources de votre projet.
+Vous pouvez éditer ces fichiers et compiler votre programme comme
+d'habitude. Votre répertoire de travail est votre propre espace privé
+de travail: Subversion ne change jamais les fichiers dans votre
+répertoire de travail, ou ne publie les modifications que vous y avez
+fait, sans que vous ne lui demandiez explicitement de le faire.
+
+Après avoir fait quelques modifications à des fichiers dans votre
+répertoire de travail et vérifié que tout fonctionne correctement,
+Subversion fournie des commandes pour publier vos modifications auprès des
+autres personnes travaillant avec vous sur votre projet. Si les autres
+publient leurs propres modifications, Subversion fournie des commandes
+pour incorporer leurs modifications dans votre répertoire de travail.
+
+Un répertoire de travail "Subversion" a des fichiers supplémentaires
+créé et maintenu par Subversion, pour l'aider à réaliser ses commandes.
+En particulier, ces fichiers aident Subversion à reconnaitre quel fichier
+contient des modifications non publiées et quels fichiers ne sont plus à
+jour par rapport au travail des autres.
+
+Alors que votre répertoire de travail vous est uniquement dédié, le
+@dfn{dépôt} est le lieu publique commun que vous partagez avec ceux
+travaillant sur le projet. Pour publier vos modifications, vous utilisez
+Subversion pour les mettre dans le dépôt. (La signification exacte de
+celà sera fournie plus loin.) Une fois que vos modifications sont dans
+le dépôt, les autres peuvent demander à Subversion d'incorporer vos
+modifications dans leurs répertoires de travail. Dans un environnement
+coopératif comme celui-ci, chaque utilisateur a son propre répertoire
+de travail (et peut-être plus d'un), et toutes les modifications dans
+les répertoires de travail seront reportées à un unique dépôt, partagé
+par tous les utilisateurs.
+
+Un dépôt Subversion conserve une unique arborescence de répertoire, et
+enregistre l'historique des modifications de cette arborescence. le
+dépôt converse suffisament d'information pour recréer tout état
+antérieurs de l'arborescence, et donner les relations entre fichiers dans
+l'arborescence --- quel fichier est dérivé quel autre fichier.
+
+Un dépôt Subversion peut converser le code source de plusieurs projets;
+habituellement, chaque projet est un sous-répertoire dans l'arborescence.
+Dans cette configuration, un répertoire de travail correspond généralement
+à un sous-répertoire particulier du dépôt.
+
+Par exemple, supposons que vous avez une dépôt organisé comme çà :
+
+@example
+/trunk/paint/Makefile
+ canvas.c
+ brush.c
+ write/Makefile
+ document.c
+ search.c
+@end example
+
+En d'autres mots, le répertoire racine du dépôt a un unique
+sous-répertoire appelé @file{trunk}, qui lui-même contient deux
+sous-répertoires: @file{paint} et @file{write}.
+
+Pour obtenir votre répertoire de travail, vous devez @dfn{descendre}
+quelques sous-arborescences du dépôt. Si vous descendez
+@file{/trunk/write} du dépôt, vous obtenez une répertoire de travail comme
+celui là :
+
+@example
+write/Makefile
+ document.c
+ search.c
+ .svn/
+@end example
+
+Ce répertoire de travail est une copie du répertoire @file{/trunk/write}
+du dépôt, avec une entrée supplémentaire --- @file{.svn} --- qui contient
+les informations nécessaires à Subversion comme mentionné plus haut.
+
+Supposons que vous modifiez @file{search.c}. Comme le répertoire
+@file{.svn} conserve la date de dernière modification du fichier et son
+contenu d'origine, Subversion peut déterniminer que vous avez modifier le
+fichier. Cependant, Subversion ne rend pas vos modifications publiques,
+tant que vous ne lui avez pas demandé explicitement.
+
+Pour publier vos modifications, vous pouvez utiliser la commande
+@samp{commit} de Subversion:
+
+@example
+$ pwd
+/home/jimb/write
+$ ls -a
+.svn/ Makefile document.c search.c
+$ svn commit search.c
+$
+@end example
+
+Maintenant que vos modifications de @file{search.c} sont remontées au
+dépôt; si un autre utilisateur descend une copie de travail de
+@file{/trunk/write}, il vera votre texte.
+
+Supposont que vous avez un collaborateur, Felix, qui a descendu un
+répertoire de travail de @file{/trunk/write} en même temps que vous.
+Lorsque vos avez remonté vos modification de @file{search.c}, la copie
+de travail de Félix est restée inchangée; Subversion ne modifie un
+répertoire de travail qu'à la demande de l'utilisateur.
+
+[Note du traducteur]
+"check out" a été traduit par "descendre" ce qui est satisfesant.
+"commit" a été pris dans le sens "check in" et traduit par "remonter".
+Ceci est moins satisfesant. "commit" est plustôt le sens "soumettre une
+requête de modification". Cette requête peut aboutir ou non.
+Par exemple, "your changes have been committed to the repository" peut se
+traduire par "vos modifications ont été acceptéss et appliquées au dépôt".
+Je l'ai réduit à "vos modifications ont été remontées au dépôt".
+Heureusement, l'expression "check in" est souvent utilisée à la place de
+"commit". Malheureusement, le terme "remonté" s'applique très mal aux
+parties techniques.
+
+Pour mettre à jour son répertoire de travail, Felix peut utiliser la
+commande @samp{update} de Subversion. Celà incorporera vos modifications
+dans son répertoire de travail, ainsi que tout ce qui a été remonté
+jusqu'à sa demande de mise à jour:
+
+@example
+$ pwd
+/home/felix/write
+$ ls -a
+.svn/ Makefile document.c search.c
+$ svn update
+U search.c
+$
+@end example
+
+Le sortie de la commande de @samp{svn update} indique que Subversion à
+mise à jour le contenu de @file{search.c}. Notons que Felix n'a pas besoin
+de spécifier quels fichiers doivent être mise à jour; Subversion utilise
+les informations dans le répertoire @file{.svn} ainsi que des informations
+dans le dépôt pour déterminer quels fichiers doivent d'être mise à
+jour.
+
+Nous expliquerons plus loin ce qui se passe lorsque vous et Felix avez
+fait des modifications au même fichier.
+
+
+@node Transactions et numéro de révision
+@subsubsection Transactions et numéro de révision
+
+Une opération @samp{commit} (remonté) de Subversion peut publier des
+modifications de plusieurs fichiers et répertoires dans une unique et
+atonique transaction. Dans votre répertoire de travail, vous pouvez
+modifier le contenu des fichiers, créer, supprimer, renommer, copier des
+fichiers et des répertoires, puis remonter l'ensemble complet des
+modifications comme un tout.
+
+Dans le dépôt, chaque remontée est traitée comme une transaction atonique:
+soit tous les modifications remontées sont prise en compte, soit aucunes
+d'elles n'est prise en compte. Subversion essaie de maintenir cette
+atonicité même en cas de plantage de programme, de crash système, de
+problèmes de réseau, et d'autres actions de l'utilisateur. Nous appèlerons
+une "remontée" une @dfn{transaction} quand nous voudrons appuier cette
+aspect d'indivisibilité.
+
+Chaque fois que le dépôt accepte une transaction, ceci crée un nouvel état
+de l'arborescence, appelé une @dfn{révision}. A chaque résivion est
+assigné un unique nombre entier, plus grand de un que le numéro de la
+révision précedante. La numéro de révision initiale après la création d'un
+dépôt est zéro, et le dépôt est un répertoire racine vide.
+
+Contrairement à beaucoup d'autres systèmes, les numéros de révision de
+Subversion s'applique à une arborescence complète et non individuellement
+à chaque fichier. Chaque numéro de révision correspond à une arborescence
+entière.
+
+Il est important de noter que les répertoires de travail ne correspondent
+pas toujours à un unique numéro de révision du dépôt; ils peuvent contenir
+des fichiers de plusieurs différentes révisions. Par exemple, supposons
+que vous avez descendu un répertoire de travail du dépôt dont la plus
+récente révision est 4:
+
+@example
+write/Makefile:4
+ document.c:4
+ search.c:4
+@end example
+
+A ce moment, le répertoire de travail correspond exactement à la révision
+4 du dépôt. Cependant, supposons que vous faites une modification à
+@file{search.c}, et remontez cette modification. En considérant qu'il n'y
+a pas eu d'autre remontée, votre remontée a créé la révision 5 sur le
+dépôt, et votre répertoire de travail ressemble maintenant à çà :
+
+@example
+write/Makefile:4
+ document.c:4
+ search.c:5
+@end example
+
+Supposons que maintenant Felix remonte une modification au fichier
+@file{document.c}, créant ainsi la révision 6. Si vous utilisez
+@samp{svn update} pour mettre à jour votre répertoire de travail, alors
+il doit ressembler à ceci :
+
+@example
+write/Makefile:6
+ document.c:6
+ search.c:6
+@end example
+
+Les modifications de Felix à @file{document.c} apparaissent dans le
+fichier de votre copie de travail, le contenu de @file{Makefile} est
+identique dans les révisions 4, 5 et 6, mais Subversion marquera votre
+copie de travail avec la révision 6 pour indiquer qu'il correspond aussi à
+la révision 6 de l'arborescence du dépôt. Donc, après avoir fait une mise
+à jour de votre répertoire de travail depuis sa racine, votre répertoire
+de travail correspondra exactement à une révision du dépôt.
+
+
+@node Etat du répertoire de travail par rapport au dépôt
+@subsubsection Etat du répertoire de travail par rapport au dépôt
+
+Pour chaque fichier du répertoire de travail, Subversion enregistre deux
+informations essentielles.
+
+@itemize @bullet
+@item
+Quelle révision de quel fichier du dépôt votre copie de travail est basée
+dessus (on dit aussi la @dfn{révision de base} du fichier, et
+@item
+un enregistrement de la date de la dernière mise à jour de la copie
+locale.
+@end itemize
+
+En founissant ces informations lors d'échange avec le dépôt, Subversion
+peut dire dans lequel des quatres états suivants est le fichier :
+
+@itemize @bullet
+@item
+@b{Inchangé et actuel}. Le fichier est inchangé dans le répertoire de
+travail et aucune modification sur ce fichier n'a été remontée au dépôt
+depuis çà révision de base.
+@item
+@b{Localement modifié et actuel}. Le fichier a été modifié dans le
+répertoire de travail et aucune modification sur ce fichier n'a été
+remontée au dépôt depuis sa révision de base. Il y a des modifications
+locales qui n'ont pas été remontées au dépôt.
+@item
+@b{Inchangé et dépassé}. Le fichier n'a pas été modifier dans le
+répertoire de travail, mais il a été modifié dans le dépôt. Le fichier
+doit éventuellement être mise à jour pour le rendre actuel avec la
+révision publique.
+@item
+@b{Localement modifié et dépassé}. Le fichier a été modifié dans le
+répertoire de travail et dans le dépôt. Le fichier doit être mise à
+jour; Subversion tentera de fusionner les modifications publiques avec
+les modifications locales. S'il ne peut faire la fusion automatiquement
+de façon convaincante, Subversion laisse à l'utilisateur la tâche de
+résoudre les conflits.
+@end itemize
+
+La commande "status" de subversion montre l'état de tout les éléments
+dans votre copie de travail. @xref{Cycle de Travail Classique}, en
+particulier la sous-section ``Examiner vos modifications''.
+
+@node Subversion ne verrouille pas les fichiers
+@subsubsection Subversion ne verrouille pas les fichiers
+
+Subversion ne prévient pas de la modification en même temps du même
+fichier par deux (ou plus) utilisateurs. Par exemple, si vous et Felix
+avez descendu une copie de travail de @file{/trunk/write}, Subversion vous
+autorise tous les deux à modifier @file{write/search.c} dans vos
+répertoires de travail. Ensuite, la séquence suivante d'évènements a
+lieu:
+@itemize @bullet
+@item
+Supposons que Félix essaie de remonter ses modifications de
+@file{search.c} en premier. Sa remontée réussie et son texte apparait dans
+la dernière révision du dépôt.
+@item
+Lorsque que vous essayer de remonter vos modifications de @file{search.c},
+Subversion refuse votre remontée et vous dit que vous devez mettre à
+jour @file{search.c} avant de le remonter.
+@item
+Lorsque vous mettez à jour @file{search.c}, Subversion essaie de fusionner
+les modifications de Felix présentent dans le dépôt avec vos modifications
+locales. Par défaut, Subversion fait la fusion comme s'il appliquait un
+patch: si vos modifications locales ne recouvrent pas textuellement celles
+de Felix, alors tout va pour le mieux; sinon, Subversion vous laisse la
+tâche de résoudre les recouvrements de modifications. Quoiqu'il en soit,
+Subversion préserve soigneusement une copie de l'original.
+@item
+Une fois que vous avez vérifié que les modifications de Felix et vos
+modifications peuvent-être fusionnées correctement, vous pouvez remonter
+une nouvelle révision de @file{search.c} qui maintenant contient les
+modifications de tout le monde.
+@end itemize
+
+Certains systèmes de contrôle de version fournissent des ``verrouillage'',
+qui préviennent contre la modification d'un fichier si une personne
+travail déjà avec. Selon notre expérience, fusionner est préférable au
+verrouillage :
+
+@itemize @bullet
+@item
+Les modifications ne sont généralement pas en conflit, donc le
+comportement de Subversion est le bon par défaut, alors que le
+verrouillage peut empécher un travail légitime.
+@item
+Le verrouillage peut prévenir des conflits pour un fichier, mais non de
+conflits entre fichiers (par exemple, entre un fichier d'entête C et
+d'autres fichiers qui l'inclut), donc celà ne resoud pas réellement le
+problème; et finalement,
+@item
+les gens oublient souvent qu'ils ont des verrouillages en cours, ceci
+pouvant devenir une cause de délais inutiles et de frictions.
+@end itemize
+
+Bien sûr, le processus de fusion doit être sous le contrôle de
+l'utilisateur. Les patchs ne sont pas appropriés pour des fichiers au
+format strict, comme les images ou les exécutables. Subversion tente de
+vous avertir lorsque le fichier est dans un format binaire ou est d'un
+type mime différent de "text/*". Pour ces fichiers au format strict,
+Subversion vous demandera lequel des deux contenus originaux prendre (le
+contenu du dépôt ou celui de votre copie de travail).
+Voir @xref{Cycle de Travail Classique}, et plus particuliairement la
+sous-section ``Fusionner les modifications des autres''.
+
+
+@c ------------------------------------
+
+@node Utilisation de Subversion
+@subsection Utilisation de Subversion
+
+La section précédente vous a donné les grandes lignes du développement
+avec Subversion. Nous avons maintenant les connaissances nécessaires pour
+"jouer" avec Subversion avec des exemples que vous pouvez directement
+appliquer.
+
+
+@menu
+* Créer un Dépôt::
+* Créer quelques copies de travail::
+@end menu
+
+@node Créer un Dépôt
+@subsubsection Créer un Dépôt
+
+
+Le client Subversion à l'interface abstraite pour accéder à un dépôt.
+Deux implémentations d' "accès de dépôt" ("Repository Access" (RA) )
+existe actuellement comme librairie. Vous pouvez voir quelle méthode est
+disponible sur votre client Subversion :
+
+@example
+$ svn --version
+Subversion Client, version N
+compiled Jan 26 2002, 16:43:58
+
+Copyright (C) 2000-2002 CollabNet.
+Subversion is open source software, see http://subversion.tigris.org/
+
+The following repository access (RA) modules are available:
+
+* ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
+ - handles 'http' schema
+* ra_local : Module for accessing a repository on local disk.
+ - handles 'file' schema
+@end example
+
+Si vous ne voyer pas ra_local, celà signifie probablement que
+"Berkeley DB" (ou qu'un moteur de base donnée approprié) n'a pas été
+trouvé lors de la compilation de votre client. Pour utiliser les exemples
+qui suivent, l'accès de dépôt ra_local doit être disponible.
+
+Commençons par créer un nouveau dépôt vide en utilisant l'outil
+@command{svnadmin}:
+
+@example
+$ svnadmin create myrepos
+@end example
+
+Considérons que vous avez un répertoire @file{someproject} qui contient
+les fichiers que vous voulez placer sous un contrôleur de version.
+@example
+someproject/foo
+ bar
+ baz/
+ baz/gloo
+ baz/bloo
+@end example
+
+Après la création du dépôt, vous pouvez dans un premier temps y importer
+vos données en utilisant la méthode d'accès ra_local (invoqué en
+utilisant une URL 'file:') et la commande @samp{import} du client
+Subversion.
+
+@example
+$ svn import file:///usr/local/svn/repos1 someproject myproj
+[...]
+Committed revision 1.
+@end example
+
+L'exemple ci-dessus crée un nouveau répertoire @file{myproj} à la racine
+du système de fichier du dépôt et y copie tous le contenu de
+@file{someproject} .
+
+@node Créer quelques copies de travail
+@subsubsection Créer quelques copies de travail
+
+Maintenant sortons une "copie de travail" de votre projet. Pour se faire,
+nous spécifions une URL vers le répertoire du dépôt que nous voulons.
+L'option '-d' nous permet de spécifier le nom du répertoire de la copie
+de travail.
+@example
+$ svn co file:///usr/local/svn/repos1/myproj -d wc
+A wc/foo
+A wc/bar
+A wc/baz
+A wc/baz/gloo
+A wc/baz/bloo
+@end example
+
+Maintenant nous avons une copie de travail dans un répertoire local nommé
+@file{wc} et qui représente l'emplacement @file{/myproj} du dépôt.
+
+Pour le plaisir de l'exemple, dupliquons la copie de travail et faisons
+comme si cette copie appartenait à quelqu'un d'autre:
+
+@example
+$ cp -R wc wc2
+@end example
+
+A present, faisons quelques modifications à notre copie de travail
+originale:
+
+@example
+$ cd wc
+$ echo "new text" >> bar # modification du contenu de bar
+$ svn propset color green foo # Ajout d'une propriété à foo
+$ svn rm baz # programmons le répertoire baz à la suppression
+$ touch newfile
+$ svn add newfile # programmons l'ajout de newfile
+@end example
+
+Celà nous fait beucoup de modifications ! Si vous nous quittez et êtes de
+retour le lendemain, comment pouvons nous connaitre les modifications
+déjà faites ?
+
+@example
+$ svn status # Montre ce qui est localement modifié
+M ./bar
+_M ./foo
+A ./newfile
+D ./baz
+D ./baz/gloo
+D ./baz/bloo
+@end example
+
+D'après la sortie de @command{svn status}, trois éléments sont programmés
+(ou marqués) pour être supprimés ((D)elete) du dépôt, un élément est
+programmé pour être (A)jouté au dépôt et deux éléments ont leurs contenus
+(M)odifié. Pour plus de détail, relisez ce qui conserne @command{svn
+status} au chapitre 2.
+
+Maintenant nous décidons de remonter nos changements, créant ainsi la
+révision 2 dans le dépôt.
+
+@example
+$ svn commit -m "fixed bug #233"
+Sending bar
+Sending foo
+Adding newfile
+Deleting baz
+Transmitting data...
+Committed revision 2.
+@end example
+
+L'argument -m est un moyen de spécifier une @dfn{description des
+modifications}: c'est une description spécifique de notre ensemble de
+modifications envoyé au dépôt. La description des modifications est
+maintenant liée à la révision 2. Un futur utilisateur pourra lire les
+descriptions des modifications du dépôt et comprendre ce que font les
+modifications de la révision 2.
+
+Finalement, Supposons que vous êtes maintenant Felix, ou un autre
+collaborateur. Si vous allez à @file{wc2}, l'autre copie de travail que
+vous avez créé, ce repétoire de travail a besoin d'une commande
+@command{svn update} pour recevoir les modifications de la révision 2 :
+
+@example
+ $ cd ../wc2 # Changement vers la sauvegarde de la copie de travail
+ $ svn update # récupération de modification du dépôt
+ U ./bar
+ _U ./foo
+ A ./newfile
+ D ./baz
+@end example
+
+La sortie de la commande @command{update} indique à Felix que baz a été
+supprimé ((D)eleted) de sa copie de travail, que newfile a été (A)jouté à
+sa copie de travail, et que bar et foo ont eu leur contenu mise à jour
+((U)pdated).
+
+Si pour diverses raisons @file{bar} a des modifications locales faites par
+Felix, alors les modifications du server (le dépôt) doivent être
+fusionnées dans @file{bar}:
+C'est-à-dire que @file{bar} doit maintenant avoir toutes les
+modifications. Quand les modifications du serveur sont fusionnées dans le
+fichier local modifié, deux scénarios sont possibles :
+
+
+@itemize @bullet
+@item
+La fusion se passe confortablement. C'est-à-dire que les deux ensembles
+de modifications ne se recouvrent pas. Dans ce cas, @command{svn update}
+affiche un G (mer(G)ed).
+@item
+les ensembles de modifications se recouvrent et un C pour (C)onflit est
+affiché. Voir la section ??? pour des informations sur comment réaliser
+une résolution de conflit.
+@end itemize
Property changes on: ./doc/handbook/french/getting_started.texi
___________________________________________________________________
Name: svn:eol-style
+ native
Index: ./doc/handbook/french/appendices.texi
===================================================================
--- ./doc/handbook/french/appendices.texi
+++ ./doc/handbook/french/appendices.texi Tue Jul 23 05:27:55 2002
@@ -0,0 +1,664 @@
+@node Appendices
+@chapter Appendices
+
+Un certain nombre d'autres documents utiles en rapport avec Subversion.
+
+@menu
+* SVN pour les utilisateurs de CVS::
+* Versionnement des répertoires::
+* Compilation et installation::
+* Feuille de référence rapide::
+* FAQ::
+* Contribuer::
+* License::
+@end menu
+
+@c ------------------------------------------------------------------
+@node SVN pour les utilisateurs de CVS
+@section SVN pour les utilisateurs de CVS
+
+Ce document se veut un quide de démarrage rapide pour les utilisateurs
+de CVS qui désirent utiliser Subversion. Ce n'est pas un substitut à la
+"vraie" documentation ni aux manuals; mais il peut vous donner rapidement
+les différences conceptuelles lorsque vous basculerez vers Subversion.
+
+L'objectif de Subversion est de "récupérer" la base actuelle et futur des
+utilisateurs de CVS. Non seulement Subversion inclut de nouvelles
+fonctionnalités, mais tente aussi de corriger comportement "bloquant" de
+CVS. Ceci signifie que vous êtes encouragé à perdre certaines habitudes.
+
+@menu
+* Les numéros de révision sont différents maintenant::
+* Plus d'opérations déconnectés::
+* Distinction entre état et mise à jour::
+* Méta-données propriétés::
+* Version de répertoire::
+* Conflits::
+* Fichiers binaires::
+* Authorisation::
+* Modules versionnés::
+* Branches et étiquetage::
+@end menu
+
+
+@node Les numéros de révision sont différents maintenant
+@subsection Les numéros de révision sont différents maintenant
+
+Avec CVS, les numéros de révision sont par fichier. C'est parce que CVS
+utilise RCS comme "moteur"; chaque fichier a son fichier RCS correspondant
+dans le dépôt et le dépôt est en gros organisé comme la structure de
+l'arborescence de votre projet.
+
+Dans Subversion, le dépôt ressemble à un unique système de fichier. Chaque
+remontée resulte en une totalement nouvelle arborescence du système de
+fichier; par essence, le dépôt est un tableau d'arborescences. Chaqu'une
+de ces arborescences est libéllée avec un numéro de révision. Lorsque
+quelqu'un parle de la "révision 54", il parle d'une arborescence
+particuliaire (et indirectement, de l'apparence du système de fichier à la
+54ième remontée).
+
+Techniquement, il n'est pas correcte de parler de la "révision 5 de
+foo.c". Au lieu de celà, il faudrait dire "foo.c comme il apparait à la
+révision 5 de l'arborescence". Ainsi, faites attention lorsque vous faites
+des suppositions sur l'évolution d'un fichier. Avec CVS, les révisions 5
+et 6 de foo.c sont toujours différentes. Avec Subversion, il est probable
+que foo.c n'est pas de modification entre la révistion 5 et la 6.
+
+@node Plus d'opérations déconnectés
+@subsection Plus d'opérations déconnectés
+
+Ces dernières années, l'espace disque est devenu outrageusement bon marché
+et abondant contrairement à la bande passante des réseaux. Par conséquent,
+la copie de travail a été optimisée en tenant comme de la pénurie de cette
+ressource.
+
+Le répertoire administratif .svn/ sert le même objectif que le répertoire
+CVS/, sauf qu'il stocke également une copie de référence du fichier. Celà
+vous permet de réaliser de nombreuse chose hors-ligne:
+
+@itemize @bullet
+@item 'svn status'
+Vous montre les modifications locales (voir plus bas)
+@item 'svn diff'
+Vous montre les details de vos modifications
+@item 'svn ci'
+Envoit les différences au dépôts (CVS envoit toujours les fichiers
+complets !)
+@item 'svn revert'
+Supprime vos modifications.
+@end itemize
+
+Cette dernière sous-commande est nouvelle; non seulement elle supprime les
+modifications locales, mais elle déprogramme aussi des opérations comme
+l'ajout et la suppression. C'est la méthode préférée pour restaurer un
+fichier; néanmoins exécution de 'rm file; svn up' continue de fonctionner
+mais çà détourne le propos de la mise à jour. Et, pendant que nous somme
+sur ce sujet...
+
+@node Distinction entre état et mise à jour
+@subsection Distinction entre état et mise à jour
+
+Dans Subversion, nous avons essayez de supprimer beaucoup de confusion
+entre les sous-commandes 'status' (état) et 'update' (mise à jour).
+
+La commande 'status' a deux objectif: (1) montrer à l'utilisateur toutes
+les modifications locales sans sa copie de travail, et (2) montrer à
+l'utilisateur quel fichier est dépassé. Malheureusement, parce que
+l'affichage de CVS est difficile à lire, beaucoup d'utilisateur de CVS ne
+tire pas du tout avantage de cette commande. Au lieu de celà, ils ont
+développé l'habitude de lancer 'cvs up' pour rapidement voir leurs
+modifications. Bien sûr, ceci à l'effet de bord d'importer les
+modifications du dépôt que vous n'attendiez peut-être pas.
+
+Avec Subversion, nous avons essayé de supprimer ces confusions en fesant
+un affichage de 'svn status' facile à lire pour les humains et les
+parseurs (programme). Ainsi, 'svn update' affiche uniquement des
+informations sur les fichiers qui sont mise à jour et n'affiche rien sur
+les modifications locales.
+
+Voici un quide rapide de 'svn status'. Nous encouragons les nouveaux
+utilisateur de Subversion a l'utiliser tôt et souvent:
+
+@itemize @bullet
+@item 'svn status'
+Affiche tous les fichiers qui ont des modifications locales; par défaut
+il n'y a pas d'accès au réseau.
+@itemize @bullet
+@item drapeau -u
+Ajoute les fichiers qui ne sont pas à jour par rapport au dépôt.
+@item drapeau -v
+Montre @emph{toutes} les entrées sous contrôle de version.
+@item drapeau -n
+Fonctionnement non récursif.
+@end itemize
+@end itemize
+
+La commande status à deux formats d'affichage. Par défaut, le format
+"court", les modifications locales ressemble à çà:
+
+@example
+ % svn status
+ M ./foo.c
+ M ./bar/baz.c
+@end example
+
+Si vous spécifiez l'option -u ou -v, le format "long" est utilisé:
+
+@example
+ % svn status
+ M 1047 ./foo.c
+ _ * 1045 ./faces.html
+ _ * - ./bloo.png
+ M 1050 ./bar/baz.c
+ Head revision: 1066
+@end example
+
+Dans ce cas, deux nouvelles colonnes apparaissent. La seconde colonne a un
+astérique si le fichier ou le répertoire est dépassé. La troisième colonne
+montre le numéros de révision du fichier de la copie de travail. Dans
+l'exemple précédent, l'astérisque indique que `faces.html' doit être
+patché si nous faisons une mise à jour, et que `bloo.png' est un fichier
+nouvellement ajouté au dépôt (le '-' près de bloo.png signifie qu'il
+n'existe pas encore dans la copie de travail).
+
+Enfin, voici un résumé des codes d'état que vous pourrez voir:
+
+@example
+ A Ajouté
+ D supprimé (Delete)
+ R Remplacé (supprimé, puis rajouté)
+ M Modification locale
+ U mise à jour (Updated)
+ G fusionné (merGed)
+ C Conflit
+@end example
+
+Subversion a combiné les codes 'p' et 'U' de CVS dans 'U'. Quand une
+fusion ou un conflit apparait, Subversion affiche simplement 'G' ou 'C',
+au lieu d'une phrase complète.
+
+@node Méta-données propriétés
+@subsection Méta-données propriétés
+
+Une nouvelle fonctionnalité de subversion est que vous pouvez attacher des
+méta-données arbitraires à un fichier ou un répertoire. Nous appèlerons
+ces données des @dfn{propriétés}, et qui peuvent être vues comme une
+collection de paire nom/valeur attaché à chaque élément de votre copie de
+travail.
+
+Pour renseigner ou obtenir une propriété, utilisez les sous-commandes
+'svn propset' et 'svn propget'. Pour lister toutes les propriétés d'un
+objet, utilisez 'svn proplist'.
+
+Pour plus d'informations, @xref{Propriétés}.
+
+@node Version de répertoire
+@subsection Version de répertoire
+
+Subversion trace les structures d'arborescence et non seulement le contenu
+des fichiers. C'est principalement pour cette raison que Subversion a été
+écrit pour remplacer CVS.
+Voici ce que celà signifie pour vous:
+
+@itemize @bullet
+@item
+Les commandes 'svn add' et 'svn rm' marche sur les répertoires maintenant,
+comme elle marche sur des fichiers. C'est aussi le cas des commandes
+'svn cp' et 'svn mv'. Cependant, ces commandes ne font pas de
+modifications immédiates sur le dépôt. Au lieu de celà, le répertoire de
+travail est récursivement programmé pour ajout ou suppression. Aucune
+modification de dépôt n'est possible sans que vous fassiez une remontée.
+@item
+Les répertoires ne sont plus des containers muets; ils ont des nombres de
+révision comme les fichiers (Il est maintenant correcte de parler du
+"répertoire foo/ à la révision 5").
+@end itemize
+
+Allons un peu plus loin sur ce sujet. Le versionnement de répertoire est
+un problème difficile. Parce que nous voulons permettre des numéros de
+révisions différents dans un copie de travail, il y a quelque limitations
+jusqu'ou on peut abuser de ce model.
+
+D'un point de vue théorique, nous définissons "révision 5 du répertoire
+foo" une collection spécifique d'entrée de répertoire et de propriétés.
+Maintenant supposons que nous ajoutons et supprimons des fichier de foo,
+et qu'enfin nous remontions ces modificiations. Ce serait un mensonge de
+dire que nous somme toujours à la révision 5 de foo. Cependant, si nous
+augmentons le numéros de révision de foo après la remontée, c'est toujours
+incorrecte; il y a peut-être d'autre modification à foo que nous n'avons
+pas encore reçu parce que nous n'avons pas encore mise à jour.
+
+Subversion traite ce problème silencieusement en tracant les remontées
+d'ajout et de suppression dans l'espace .svn. Lorsqu'éventuellement vous
+exécuté 'svn update', tous les "compteurs" sont comparés avec le dépôt, et
+le nouveau numéros de révision est mis correctement. @b{Donc, uniquement
+après une mise à jour il est sûr de dire que vous avez une "parfaite"
+révision du répertoire.}
+
+De façon similaire, un problème se produit si vous essayez de remonter des
+modifications de propriétés d'un répertoire. Normalement, une remontée
+doit augmenter le numéros de révision locale du répertoire de travail.
+Mais encore une fois, c'est incorrecte car il peut y avoir des ajout et
+suppression que le répertoire n'a pas encore parce qu'il n'y a pas eu de
+mise à jour. @b{Donc, vous ne pouvez pas remonter des modifications de
+propriétés sur un répertoire tant que le répertoire n'est pas été mise à
+jour.}
+
+Pour plus de discussion et d'exemples spécifiques: @xref{Versionnement des
+répertoires}.
+
+
+
+@node Conflits
+@subsection Conflits
+
+CVS marque les conflits avec des "marqueurs de conflit" en ligne, et
+affiche un 'C' durant la mise à jour. Historiquement, ceci a pausé des
+problèmes. Beaucoup d'utilisateur oubliaient (ou ne voyaient pas) le
+'C' après qu'il ait défillé sur leur terminal. Ils oubliaient souvent
+que les marqueurs de conflit pouvaient être présents, et accidentellement
+remontaient des fichiers pollués.
+
+Subversion résoud ce problème en marquant les conflits de façon plus
+tangible. Pour en savoir plus lisez: @xref{Cycle de Travail Classique}.
+En particulier, lisez la section à propos de ``Fusionner les modifications
+des autres''.
+
+
+@node Fichiers binaires
+@subsection Fichiers binaires
+
+Les utilisateurs de CVS devaient marquer les fichiers binaires avec le
+drapeau '-kb' pour prévenir de modifications non désirées (à cause des
+substitutions de mots-clé et des translations de fin de ligne). Ils
+oubliaient parfois de faire çà.
+
+Subversion examine la propriété "svn:mime-type" pour décider si le fichier
+est de type texte ou binaire. Si le fichier n'a pas de propriété
+"svn:mime-type", Subversion considère qu'il est de type texte. Si le
+fichier a la propriété "svn:mime-type" mise à autre chose que "test/*",
+Subversion considère que le fichier est binaire.
+
+Subversion aide l'utilisateur en tentant de détecter la présence d'un
+fichier binaire lors d'un 'svn import' ou 'svn add'. Si le fichier est
+considéré comme binaire par ces commandes, elles mettent la propriété
+"svn:mime-type" à "application/octet-stream" au fichier qui vient d'être
+ajouté. Si Subversion s'est trompé lors de sa détection, vous pouvez
+toujours supprimer ou éditer la propriété.
+
+Comme avec CVS, les fichiers binaires ne sont pas sujet à l'expansion des
+mots-clé ou à une conversion des fins de ligne. Et lorsqu'un fichier
+binaire est "fusionné" durant une mise à jour, il n'y a pas de réelle
+fusion de réalisée. Au lieu de celà, Subversion crée deux fichiers dans
+votre copie de travail (un fichier correspondant au dépôt et un autre à
+votre copie de travail). Celui avec vos modifications locales est renommé
+avec l'extension ".orig".
+
+@node Authorisation
+@subsection Authorisation
+
+Contrairement à CVS, SVN gère les utilisateurs authorisés et les anonymes
+avec le même dépôt. Il n'y a pas de nécessité de créer un utilisateur
+anonyme ou un dépôt séparé. Si le serveur SVN demande une authorisation
+lors d'une remontée, le client vous demandera votre authorisation (mot
+de passe).
+
+
+@node Modules versionnés
+@subsection Modules versionnés
+
+Contrairement à CVS, une copie de travail de Subversion à conscience
+d'avoir sorti un module. Ceci signifie que si quelqu'un change la
+définition d'un module, alors la commende @command{svn up} mettra à jour
+la copie de travail de façon appropriée.
+
+Subversion defines modules as a list of directories within a directory
+property. @xref{Modules}.
+
+Subversion défini les modules comme une liste de répertoire dans une
+propriété d'un répertoire. @xref{Modules}.
+
+
+@node Branches et étiquetage
+@subsection Branches et étiquetage
+
+Subversion n'a pas de séparation entre l'espace du système de fichier et
+l'espace des ``branches''; les branches et les étiquettes sont des
+répertoires ordinaires dans le système de fichier. C'est probablement le
+seule gros obstacle mental qu'un utilisateur de CVS doit surmonter.
+Lisez tout à propos de çà: @xref{Branche et Etiquetage}.
+
+
+@c ------------------------------------------------------------------
+@node Versionnement des répertoires
+@section Versionnement des répertoires
+
+@quotation
+@emph{"The three cardinal virtues of a master technologist are:
+laziness, impatience, and hubris." -- Larry Wall}
+@end quotation
+
+Cette appendice décrit quelques pièges théoriques autour de la notion
+(peut-être arrogante) qu'un répertoire peut-être aussi simplement
+versionné qu'un fichier.
+
+@subsection Révision de répertoire
+
+Pour commencer, rappelez vous que le dépôt de Subversion est un tableau
+d'arborescences. Chaque arborescence représente l'application d'une
+nouvelle remontée atonique et est appelée une @dfn{révision}. C'est très
+différent du dépôt de CVS qui stocke l'historique des fichiers dans une
+collection de fichiers RCS (et qui ne peut pas tracer les modifications de
+structure de l'arborescence).
+
+Ainsi, lorsque nous nous référons à la "révision 4 de foo.c" (aussi écrit
+@dfn{foo.c:4}) dans CVS, celà signifie la quatrième version distincte de
+@file{foo.c} -- mais dans Subversion celà signifie "la version de foo.c
+à la quatrième révision (de l'arborescence)". Alors qu'il est probable
+que @file{foo.c} n'est jamais changé depuis la révision 1! En d'autres
+termes, avec Subversion, différents numéros de révision du même élément
+versionné n'impliquent @emph{pas} différents contenus.
+
+Néanmoins, le contenu de @samp{foo.c:4} reste parfaitement défini. Le
+fichier @file{foo.c} dans la révision 4 a un contenu et des propriétés
+spécifiques.
+
+Supposons, maintenant, que nous étendions ce concept aux répertoires. Si
+nous avons un répertoire @file{DIR}, défini @dfn{DIR:4} comme "le
+répertoire DIR à la quatrième révision". Le contenu est défini comme étant
+un ensemble particulier d'entrées de répertoire (@dfn{dirents}) et de
+propriétés.
+
+Le concept de versionnement de répertoire semble bon dans le dépôt -- le
+dépôt est basée sur une théorie très pûre. Cependant, à cause des copies
+de travail qui authorisent le mixage de révisions, il est simple de créer
+des cas utilisateurs problématiques.
+
+@subsection Le répertoire à la traine
+
+@subsubsection Problème
+
+@c This is the first part of of the "Greg Hudson" problem, so named
+@c because he was the first one to bring it up and define it well. :-)
+
+Supposons que votre copie de travail a un répertoire @samp{DIR:1}
+contenant le fichier @samp{foo:1} avec quelques autres fichiers. Nous
+supprimons @file{foo} et remontons la modification.
+
+Immédiatement, nous avons un problème: notre copie de travail continue de
+prétendre avoir @samp{DIR:1}. Mais sur le dépôt, la révision 1 de DIR est
+@emph{définie} comme contenant @samp{foo} -- et notre copie de travail ne
+l'a manifestement plus. Comme puis-je dire que nous avons encore
+@samp{DIR:1}?
+
+Une réponse à ce problème, est de forcer DIR à être mise à jour lorsque
+nous remontons la suppression de @file{foo}. En considérant que notre
+remontée créée la révision 2, nous devons immédiatement mettre à jour
+notre copie de travail à @samp{DIR:2}. Alors le client et le serveur sont
+tous les deux d'accords que @samp{DIR:2} ne contient pas foo et que
+@samp{DIR:2} est exactement ce qu'il est dans la copie de travail.
+
+Cette solution est mauvaise car avec des effets du bord sur la
+convivialité à l'utilisation. Imaginons que d'autres personnes remontent
+des modifications avant nous, en ajoutant de nouvelles propriétés à DIR ou
+en ajoutant un nouveau fichier @file{bar}. Maintenant supposons que notre
+remontée de suppression ait créé la révision 5 dans le dépôt. Si nous
+mettons à jours instantanément notre répertoire DIR local à la révision 5,
+ceci signifie la réception non prévue d'une copie de @file{bar} et des
+changements de propriétés. Ceci viole clairement un principe l'interface
+utilisateur: "le client n'a jamais de changements de sa copie de travail
+tant qu'il ne l'a pas demandé." . Remonter des modifications au dépôt est
+une opération d'écriture sur le serveur uniquement; ceci ne doit
+@emph{pas} modifier nos données de travail !
+
+Une autre solution, est de faire cette chose naïve: après la remontée de
+la suppression de @file{foo}, arrêter tout simplement de tracer le fichier
+dans le répertoire administratif @file{.svn}. Le client perd alors toute
+connaissance du fichier.
+
+Mais çà ne marche pas non plus: si maintenant nous mettons à jour notre
+copie de travail, la communication entre le client et le serveur est
+incorrecte. Le client continue de croire qu'il a @samp{DIR:1} -- ce qui
+est faut, puisque le "vrai" @samp{DIR:1} contient @file{foo}. Le client
+donne ce rapport incorrect au dépôt, et le dépôt décide que pour mettre à
+jour à la révision 2, @file{foo} doit être supprimé. Ainsi le dépôt envoie
+une commande de suppression bugguée (ou au moins inutile).
+
+@subsubsection Solution
+
+Après la suppresion de @file{foo} et sa remontée, le fichier n'est
+@emph{pas} totalement oublié par le répertoire @file{.svn}. Alors que le
+fichier n'est plus considéré comme étant sous contrôle de révision, il est
+secrètement conservé comme ayant été `supprimé'.
+
+Lorsque l'utilisateur met à jour sa copie de travail, le client informe
+correctement le serveur que le fichier est actuellement manquant dans
+son répertoire @samp{DIR:1} local; donc le dépôt n'essaie pas de le
+supprimer à nouveau lorsqu'il patch le client vers la révision 2.
+
+@c Notes, for coders, about how the `deleted' flag works under the hood:
+
+@c * the `svn status' command won't display a deleted item, unless
+@c you make the deleted item the specific target of status.
+@c
+@c * when a deleted item's parent is updated, one of two things will happen:
+@c
+@c (1) the repository will re-add the item, thereby overwriting
+@c the entire entry. (no more `deleted' flag)
+@c
+@c (2) the repository will say nothing about the item, which means
+@c that it's fully aware that your item is gone, and this is
+@c the correct state to be in. In this case, the entire entry
+@c is removed. (no more `deleted' flag)
+@c
+@c * if a user schedules an item for addition that has the same name
+@c as a `deleted' entry, then entry will have both flags
+@c simultaneously. This is perfectly fine:
+@c
+@c * the commit-crawler will notice both flags and do a delete()
+@c and then an add(). This ensures that the transaction is
+@c built correctly. (without the delete(), the add() would be
+@c on top of an already-existing item.)
+@c
+@c * when the commit completes, the client rewrites the entry as
+@c normal. (no more `deleted' flag)
+
+
+@subsection Le répertoire en avance
+
+@c This is the 2nd part of the "Greg Hudson" problem.
+
+@subsubsection Problème
+
+Supposons que notre copie de travail a le répertoire @samp{DIR:1}
+contenant @samp{foo:1} ainsi que d'autres fichiers.
+
+Maintenant, sans que nous le sachions, quelqu'un d'autre ajoute un nouveau
+fichier @file{bar} à ce répertoire, créant ainsi la révision 2 (et
+@samp{DIR:2}).
+
+Maintenant nous ajoutons une propriété à @file{DIR} et le remontons, ce
+qui crée la révision 3. Notre copie de travail de @file{DIR} est marquée
+comme étant la révision 3.
+
+Bien sûr, c'est faut; notre copie de travail n'est @emph{pas}
+@samp{DIR:3}, car le "vrai" @samp{DIR:3} dans le dépôt contient un nouveau
+fichier @file{bar}. Notre copie de travail n'a pas du tout connaissance de
+@file{bar}.
+
+Encore un fois, nous ne pouvons faire suivre notre remontée de @file{DIR}
+par une mise à jour automatique (donc avec l'ajout de @file{bar}). comme
+indiqué précédament, les remontées sont des opérations décritures à un
+seul sens; elles ne doivent pas modifier les données de la copie de
+travail.
+
+@subsubsection Solution
+
+Enumérons exactement quand un numéros de révision d'un répertoire local
+change:
+
+@itemize @bullet
+@item
+@b{quand un répertoire est mise à jour}: si le répertoire est soit la
+cible directe d'une commande de mise à jour, soit le fils d'un répertoire
+mise à jour, il est alors augmenté (avec d'autres frère et fils) à un
+numéros de révision uniforme.
+@item
+@b{quand un répertoire est remonté}: un répertoire peut-être considéré
+comme un "objet remonté" uniquement s'il a une nouvelle modification de
+propriété. (autrement, "remonter un répertoire" implique que ces fils
+modifiés ait été remontés, et uniquement de tel fils auront leur révision
+augmenté.)
+@end itemize
+
+A la lumière de ces explications, il est claire que notre problème de
+"répertoire en avance" apparait uniquement dans la seconde situation --
+aux moments où nous remontons des modifications de propriété d'un
+répertoire.
+
+Donc la réponse est simplement de ne pas permettre la remontée de
+propriété d'un répertoire qui est dépassé. Celà semble un peu restrictif,
+mais il n'y a pas d'autre moyen pour conserver les révisions de répertoire
+cohérentes.
+
+@c Note to developers: this restriction is enforced by the filesystem
+@c merge() routine.
+
+@c Once merge() has established that {ancestor, source, target} are all
+@c different node-rev-ids, it examines the property-keys of ancestor
+@c and target. If they're *different*, it returns a conflict error.
+
+
+@subsection User impact
+
+Donc, le client Subversion semble avoir deux difficiles --- et
+principalement contradictoires --- objectifs.
+
+Premièrement, il doit rendre sont utilisation conviviale, ce qui
+généralement signifie une système de décision peu claire quant à ce que
+peut ou non faire l'utilisateur. C'est pourquoi il permet une copie de
+travail avec plusieurs révisions, et pourquoi il essaie de lancer
+l'utilisateur réaliser des opérations de modification locale de
+l'arborescence (suppression, ajout, déplacement, copie) dans des
+situations qui ne sont pas toujour parfaites, théoriquement "sûres" ou
+pures.
+
+Deuxièment, le client essaie de conserver la copie de travail cohérente et
+synchronisée avec le dépôt en utilisant le minimum de communication
+possible. Bien sûr, ceci est rendu plus difficile avec le premier
+objectif!
+
+Finallement, il y a quelques tensions ici, et la résolutions des problèmes
+peut varier. Dans un cas (le "répertoire en avance"), le problème peut
+être résoud avec un peu d'astuce dans le traçage des entrées par le
+client. Dans l'autre cas ("le répertoire dépassé"), la seule solution est
+de restreindre quelques négligences théoriques authorisées par le client.
+
+@c ------------------------------------------------------------------
+@node Compilation et installation
+@section Compilation et installation
+
+Les dernières instructions pour compiler et installer Subversion (et
+httpd-2.0) sont maintenues dans le fichier @file{INSTALL} à la racine des
+sources de Subversion.
+
+En général, vous devrez aussi être capable de trouver la dernière version
+de ce fichier en le récupérant directement depuis notre dépôt de
+Subversion:
+@url{http://svn.collab.net/repos/svn/trunk/INSTALL}
+
+
+@c ------------------------------------------------------------------
+@node Feuille de référence rapide
+@section Feuille de référence rapide
+
+Une feuille de référence rapide (Ndt : il doit exister mieux comme
+traduction ?) est téléchargable sur le site web de Subversion, qui est
+compilé depuis le fichier dans le répertoire @file{doc/user/quickref}.
+Il y a-t-il un volontaire pour la réécrire en texinfo ?
+
+
+
+@c ------------------------------------------------------------------
+@node FAQ
+@section FAQ
+
+La FAQ principale du projet peut être vue directement dans le dépôt de
+Subversion:
+
+@url{http://svn.collab.net/repos/svn/trunk/www/project_faq.html}
+
+
+@c ------------------------------------------------------------------
+@node Contribuer
+@section Contribuer
+
+Pour une description complète sur comment contribuer à Subversion, lisez
+le fichier @file{HACKING} à la racine des sources de Subversion. Il est
+aussi disponible à @url{http://svn.collab.net/repos/svn/trunk/HACKING}.
+
+Subversion est comme beaucoup de projets open-source. Commencez par
+participer aux discussions sur les mailling listes, puis en proposant des
+patchs à la critique. Eventuellement, on vous accordera les droits pour
+accéder en écriture au dépôt.
+
+@c ------------------------------------------------------------------
+@node License
+@section License
+
+Copyright @copyright{} 2002 Collab.Net. All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are
+met:
+
+@enumerate
+@item
+Redistributions of source code must retain the above copyright notice,
+this list of conditions and the following disclaimer.
+
+@item
+Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in the
+documentation and/or other materials provided with the distribution.
+
+@item
+The end-user documentation included with the redistribution, if
+any, must include the following acknowledgment: "This product includes
+software developed by CollabNet (http://www.Collab.Net/)."
+Alternately, this acknowledgment may appear in the software itself, if
+and wherever such third-party acknowledgments normally appear.
+
+@item
+The hosted project names must not be used to endorse or promote
+products derived from this software without prior written
+permission. For written permission, please contact info@@collab.net.
+
+@item
+Products derived from this software may not use the "Tigris" name
+nor may "Tigris" appear in their names without prior written
+permission of CollabNet.
+
+@item
+THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
+WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+IN NO EVENT SHALL COLLABNET OR ITS CONTRIBUTORS BE LIABLE FOR ANY
+DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
+GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
+IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+@end enumerate
+
+This software consists of voluntary contributions made by many
+individuals on behalf of CollabNet.
+
+
+
+
+
+
Property changes on: ./doc/handbook/french/appendices.texi
___________________________________________________________________
Name: svn:eol-style
+ native
Index: ./doc/handbook/french/svn-handbook-french.texi
===================================================================
--- ./doc/handbook/french/svn-handbook-french.texi
+++ ./doc/handbook/french/svn-handbook-french.texi Tue Jul 23 05:27:55 2002
@@ -0,0 +1,141 @@
+\input texinfo @c -*-texinfo-*-
+
+@comment Subversion Handbook
+@comment Copyright (C) 2002 CollabNet
+
+@c ================================================================
+@c Copyright (c) 2002 CollabNet. All rights reserved.
+@c
+@c Redistribution and use in source and binary forms, with or without
+@c modification, are permitted provided that the following conditions are
+@c met:
+@c
+@c 1. Redistributions of source code must retain the above copyright
+@c notice, this list of conditions and the following disclaimer.
+@c
+@c 2. Redistributions in binary form must reproduce the above copyright
+@c notice, this list of conditions and the following disclaimer in the
+@c documentation and/or other materials provided with the distribution.
+@c
+@c 3. The end-user documentation included with the redistribution, if
+@c any, must include the following acknowledgment: "This product includes
+@c software developed by CollabNet (http://www.Collab.Net/)."
+@c Alternately, this acknowledgment may appear in the software itself, if
+@c and wherever such third-party acknowledgments normally appear.
+@c
+@c 4. The hosted project names must not be used to endorse or promote
+@c products derived from this software without prior written
+@c permission. For written permission, please contact info@collab.net.
+@c
+@c 5. Products derived from this software may not use the "Tigris" name
+@c nor may "Tigris" appear in their names without prior written
+@c permission of CollabNet.
+@c
+@c THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
+@c WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+@c MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+@c IN NO EVENT SHALL COLLABNET OR ITS CONTRIBUTORS BE LIABLE FOR ANY
+@c DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+@c DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
+@c GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+@c INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
+@c IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+@c OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+@c ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+@c
+@c ====================================================================
+@c
+@c This software consists of voluntary contributions made by many
+@c individuals on behalf of CollabNet.
+
+@c Note du traducteur :
+@c
+@c * Cette traduction est un traduction qui suit au plus près la version
+@c anglaise.
+@c * Je ne connais pas le format .texi. Il doit donc y avoir des erreurs.
+@c
+@c * Cette traduction s'est appuiée sur la version 2576 de Subversion.
+@c
+@c * voici certaine correspondance anglais-français.
+@c - handbook => manuel
+@c - revision control system => système de contrôle de version
+@c - commit => requête de prise en compte de changement.
+@c - commit => requête de changement.
+@c - commit => souvent considéré comme "check in"
+@c - hackability => capacité d'adaptation.
+@c - pristine version => version de référence.
+@c - check out => descendre
+@c - check in => remonter
+@c - out-of-date => dépassé
+@c - current => actuel
+@c - log message => description de modification
+@c - time machine => rien. Les phrases qui utilise çà ont été zappées.
+
+@c %**start of header
+@setfilename svn-handbook-french.info
+@settitle Guide de Subversion
+@setchapternewpage odd
+@c %**end of header
+
+@paragraphindent 0
+
+@c @finalout
+
+@c Browser defaults lose. Let's go for black text on white background.
+@ifhtml
+@html
+<body bgcolor="#FFFFFF" fgcolor="#000000">
+@end html
+@end ifhtml
+
+@c -----------------------------------------------------------------
+@titlepage
+@title @titlefont{The Subversion Handbook}
+@author Subversion Development Project @url{http://subversion.tigris.org}
+
+@page
+@vskip 0pt plus 1filll
+Copyright @copyright{} 2002 CollabNet, Inc. @*
+See @ref{License} for details. @*
+First version: June 2002. @*
+$LastChangedDate: 2002-07-23 01:24:41 -0400 (mar, 23 jui 2002) $
+
+@end titlepage
+@c -----------------------------------------------------------------
+
+@c @summarycontents
+@c @contents
+
+@node Top
+@top
+
+@ifinfo
+Ce manuel est un guide du système de contrôle de version Subverion.
+
+Ndt: C'est la traduction du manual en anglais de la révision 2610
+(pré 0.13.3 ?).
+Je n'ai pas fait cette traduction pour devenir un "fork" de la version
+anglaise. Ainsi, beaucoups d'erreurs/manquements de la version anglais
+sont dans cette traduction. Les corrections seront faites (peut-être)
+lorsque la version anglaise sera corrigée. Ceci est pour des raisons
+évidentes de maintenance de cette traduction.
+Je ne suis pas très satisfait de la traduction dans les parties très
+techniques. J'espère néanmoins qu'elle vous sera utile.
+
+@end ifinfo
+
+@c Here is our logical table of contents.
+
+@menu
+* Débuter avec Subversion:: Historique, installation et vue d'ensemble de Subversion.
+* Utilisation des clients:: Utilisation des clients de subversion.
+* Administration des Dépôts:: Gestion des dépôts.
+* Appendices:: D'autres documents et références.
+@end menu
+
+@include getting_started.texi
+@include client.texi
+@include repos_admin.texi
+@include appendices.texi
+
+@bye
Property changes on: ./doc/handbook/french/svn-handbook-french.texi
___________________________________________________________________
Name: svn:keywords
+ Date
Name: svn:eol-style
+ native
Index: ./doc/handbook/french/client.texi
===================================================================
--- ./doc/handbook/french/client.texi
+++ ./doc/handbook/french/client.texi Tue Jul 23 05:27:55 2002
@@ -0,0 +1,1306 @@
+@node Utilisation des clients
+@chapter Utilisation des clients
+
+Comment bien utiliser votre client Subversion en 11 étapes.
+
+Ce chapitre décrit plus en détail les commandes client.
+Pour une vue d'ensemble du mode de développement ``copier-modifier-fusionner''
+avec un clients de type CVS, @xref{Concepts}.
+
+@menu
+* descente::
+* Cycle de Travail Classique::
+* Historique::
+* Branche et Etiquetage::
+* Propriétés::
+* Modules::
+* Autres commandes::
+@end menu
+
+@c ------------------------------------------------------------------
+@node descente
+@section descente
+
+La plupart du temps, vous commencerez l'utilisation d'un dépôt Subversion
+en réalisant une @dfn{descente} de votre projet. l'opération de
+"descendre" vous fournit une copie de la tête (dernière révision) du dépôt
+Subversion que vous descendez.
+
+@example
+$ svn co http://svn.collab.net/repos/svn/trunk
+A trunk/subversion.dsw
+A trunk/svn_check.dsp
+A trunk/COMMITTERS
+A trunk/configure.in
+A trunk/IDEAS
+...
+Checked out revision 2499.
+@end example
+
+Bien que l'exemple descend le répertoire trunk, vous pouvez de la même
+manière descendre n'importe quel sous-répertoire du dépôt en spécifiant le
+sous-répertoire dans URL à descendre.
+
+@example
+$ svn co http://svn.collab.net/repos/svn/trunk/doc/handbook
+A handbook/svn-handbook.texi
+A handbook/getting_started.texi
+A handbook/outline.txt
+A handbook/license.texi
+A handbook/repos_admin.texi
+A handbook/client.texi
+Checked out revision 2499.
+@end example
+
+Puisque Subversion utilise le model ``copier-modifier-fusionner'' au-lieu
+de ``verrouiller-modifier-déverrouiller'', vous êtes imédiatement prêt
+pour modifier les fichiers que vous venez de descendre. Ensemble des
+fichiers descendu est votre @dfn{copie de travail}. Vous pouvez aussi
+supprimer toute votre copie de travail sans conséquence (sauf si vous
+étiez sur le point de @dfn{remonter} des modifications, un nouveau fichier
+voir un répertoire). La suppression d'une copie de travail ne nécessite
+pas d'en informer le serveur Subversion.
+
+Tout les répertoire de la copie de travail ont un @dfn{espace
+d'administration}, un sous-répertoire nommé @file{.svn}. La @command{ls}
+ne montre pas par défaut ce répertoire. Quoique vous fassiez, ne
+supprimez et ne changez rien dans cet espace d'administration ! Pour
+gérer votre copie de travail, Subversion en a besoin.
+
+Vous pouvez exécuter @command{svn help checkout} pour connaitre les
+options de la ligne commande permettant la descente. Une options est très
+commune: @samp{--destination} (@samp{-d}). Ceci place votre copie de
+travail dans le nouveau répertoire que vous avez spécifié. Par exemple:
+
+@example
+$ svn co http://svn.collab.net/repos/svn/trunk -d subv
+A subv/subversion.dsw
+A subv/svn_check.dsp
+A subv/COMMITTERS
+A subv/configure.in
+A subv/IDEAS
+...
+Checked out revision 2499.
+@end example
+
+@c ------------------------------------------------------------------
+@node Cycle de Travail Classique
+@section Cycle de Travail Classique
+
+Subversion a de nombreuses fonctions et options, mais dans une utilisation
+quotidien classique vous en utiliserez qu'un nombre limité d'elles. Dans
+cette section nous présentons les opérations les plus classiques qui
+sont rencontrées lorsque vous travaillez avec Subversion.
+
+Le cycle typique d'utilisation de Subversion ressemble à ceci :
+
+@itemize @bullet
+@item
+Mise à jour de votre copie de travail
+@item
+Faire des modifications
+@item
+Examiner vos modifications
+@item
+Fusionner les modifications des autres
+@item
+Remonter vos modifications
+@end itemize
+
+@c ---------------
+@subsection Mise à jour de votre copie de travail (svn update)
+
+En travaillant en équipe sur un projet, vous allez @dfn{mettre à jour}
+votre copie de travail: c'est-à-dire, récupérer les changements des autres
+développeurs du projet.
+@example
+$ svn up
+U ./foo.c
+U ./bar.c
+Updated to revision 2.
+@end example
+
+Dans cet exemple, une autre personne a remonté des modifications de
+@file{foo.c} et @file{bar.c} depuis la dernière fois que vous
+avez mise à jour, Subversion à mise à jour vour copie de travail
+pour inclure ces modifications.
+
+Examinons la sortie de @samp{svn update} un peu plus. Lorsque le serveur
+envoie des modifications à votre copie de travail, un code est affiché a
+côté de chaque élément:
+
+@table @b
+@item U foo
+Le fichier @file{foo} a été mise à jour ((U)pdated) (modifications reçues
+du serveur) dans votre copie de travail.
+@item A foo
+Le fichier ou répertoire @file{foo} a été (A)jouté à votre copie de
+travail.
+@item D foo
+Le fichier ou réportoire @file{foo} a été supprimé ((D)eleted) de votre
+copie de travail.
+@item R foo
+Le fichier ou répertoire @file{foo} a été (R)emplacé dans votre copie de
+travail; c'est-à-dire, @file{foo} a été supprimé, et un nouvelle élément
+avec le même mot a été ajouté. Bien qu'il est le même nom, le dépôt les
+considère comme des objects distincts avec des historiques distincts.
+@item G foo
+Le fichier @file{foo} a reçu de nouvelles modifications du dépôt, mais il
+a aussi des modifications réalisées par vous-même. Les modifications
+n'intéragissent pas entre elles cependant, donc Subversion a pu fusionner
+(mer(G)ed) les modifications du dépôts dans le fichier sans problème.
+@item C foo
+Le fichier a reçu des modifications conflictuelles du serveur. les
+modifications du server recouvre vous propres modifications du fichier.
+Inutile de paniquer cependant. Ce recouvrement doit est résolu par un
+humain (peut-être vous); nous aborderons cette situation plus loin.
+@end table
+
+@subsection Faire des modifications (svn add, rm, cp, mv)
+
+Maintenant vous pouvez travailler et réaliser quelques modifications dans
+votre copie de travail.
+
+Nous vérons quel type de modification vous pouvez faire dans à votre
+copie de travai.
+
+@table @b
+@item Modification de fichier
+c'est le type de changement le plus simple. Contrairement à d'autre
+système de contrôle de version, nous n'avez pas besoin de dire à
+Subversion que vous avez l'intention de modifier un fichier; faites le.
+Plus tard, Subversion est capable de détecter automatiquement quel fichier
+a été modifié.
+@item Modification d'arborescence
+Vous pouvez demander à Subversion de 'marquer' des fichiers et des
+répertoire pour la suppresion ou d'addition dans le dépôt. Evidament,
+aucun ajout ou suppresion n'est réalisé dans le dépôt sans une remontée
+explite de votre part.
+@end table
+
+Pour faire des modifications de fichiers, utilisez votre éditeur de texte,
+votre traitement de texte, ou n'importe quelle méthode. Un fichier ne doit
+pas nécessairement être au format texte; les fichiers binaires sont
+également parfaitement pris en charge.
+
+Il y a au moins quatre commandes Subversion pour faire des modifications
+de l'arborescence. Une aide détaillée peut être abtenue avec @command{svn
+help}. Néanmoins, voici un résumé:
+
+@table @command
+@item svn add foo
+Programme l'ajout de @file{foo} dans le dépôt. Lors de votre prochaine
+remontée, @file{foo} deviendra un fils permanent de son répertoire
+parent. Notons que si @file{foo} est un répertoire, seul le répertoire
+sera programmé pour l'ajout. Si vous voulez ajouter son contenu également,
+ajouté le drapeau @samp{--recursive}.
+@item svn rm foo
+Programme la suppression de @file{foo} dans le dépôt. @file{foo} est un
+fichier, Subversion le fait disparaitre de la copie de travail -- mais il
+peut être restauré avec @command{svn revert} (voir plus loin). Si
+@file{foo} est un répertoire, il est simplement programmé pour la
+suppression. Après votre remontée, @file{foo} n'existera plus dans la
+copie de travai ni dans le dépôt.
+@item svn cp foo bar
+Crée un nouvelle élément @file{bar} qui est un double de @file{foo}.
+@file{bar} est automatique programmé pour l'addition. Lors de l'ajout
+de @file{bar} au dépôt à la prochaine remontée, c'est une
+copie-historique qui est enregistré (enregistre que le contenu initiale de
+@file{bar} vient de @file{foo}).
+@item svn mv foo bar
+C'est commande est équivalente à @command{svn cp foo bar; svn rm foo}.
+C'est-à-dir, @file{bar} est programmé pour l'addition en tant que copie
+de @file{foo}, et @file{foo} est programmé pour la suppresion.
+@end table
+
+@subsection Examiner vos modifications (svn status, diff, revert)
+
+Donc maintenant que vous avez fini vos modification... vous vous dites:
+Quelle sont les modifications que j'ai fait ? Comment les consulter?
+
+Subversion a été optimisé pour vous aider dans cette tâche, et il est
+capable de faire plein de choses sans accéder au dépôt ou utiliser le
+réseau. Votre copie de travail possède une copie de référence caché de
+chaque fichier et répertoire dans l'aspace @file{.svn}. Cette copie de
+référence correspond au dernier état connu du dépôt. Grâce à çà,
+Subversion peut rapidement vous montrer les modifications faites sur
+votre copie de travail, ou eventuellement vous permettre d'annuler vos
+modification dans le répertoire de copie.
+
+La commande @command{svn staus} est votre ami; devenez intime avec elle.
+Vous utiliserez @command{svn status} probablement plus que n'importe
+quelle autre commande.
+
+Si vous exécutez @command{svn status} à la racine de votre copie de
+travail sans arguments, il donnera toutes les modifications de fichiers
+et d'arborescence que vous avez fait :
+
+@example
+$ svn status
+M ./bar.c
+M ./README
+D ./stuff/fish.c
+A ./stuff/things/bloo.h
+@end example
+
+Ici, la commande status dit que vous avez (M)odifier deux fichiers,
+programmé un autre pour (A)jout, programmé un autre pour la suppression
+((D)eletion).
+Si un chemin est donné à la commande, les informations fournies seront
+limités à ce chemin.
+
+@example
+$ svn status stuff/fish.c
+D ./stuff/fish.c
+@end example
+
+Cette commande a aussi un mode verbeux (@samp{--verbose} ou @samp{-v}),
+qui montrera l'état de @emph{tous} les éléments dans votre copie de
+travail:
+
+@example
+$ svn status -v
+M 44 23 joe ./README
+_ 44 30 frank ./INSTALL
+M 44 20 frank ./bar.c
+_ 44 18 joe ./stuff
+_ 44 35 mary ./stuff/trout.c
+D 44 19 frank ./stuff/fish.c
+_ 44 21 mary ./stuff/things
+A 0 ? ? ./stuff/things/bloo.h
+_ 44 36 joe ./stuff/things/gloo.c
+@end example
+
+Ceci est la ``forme long'' de l'affichage de @command{svn status}. La
+premier colonne est inchangée. La seconde colonne fournie le numéro de
+révision de la copie de travail de l'élément. La troisième et quatrième
+colonne montre la révision de dernière modification de l'élément et qui
+l'a modifié.
+Enfin, il y a le drapeau @samp{--show-update} (@samp{-u}), qui
+contact le dépôt et ajoute des informations sur ce qui est dépassé:
+@example
+$ svn status -u
+M * 44 23 joe ./README
+M 44 20 frank ./bar.c
+_ * 44 35 mary ./stuff/trout.c
+D 44 19 frank ./stuff/fish.c
+A 0 ? ? ./stuff/things/bloo.h
+@end example
+
+Remarquer les deux astérisques: si vous lancez @command{svn up}
+maintenant, vous recevrez des modifications pour @file{README} et
+@file{trout.c}. Soyez prudent. Vous devez absorber ces modifications du
+serveur pour @file{README} avant de le remonter au risque de voir votre
+remontée refusée car votre fichier est dépassé (plus d'information sur ce
+sujet plus bas). Nous devons également mentionner deux autres codes d'état
+que vous pouvez voir:
+
+@example
+$ svn status
+? ./foo.o
+! ./foo.c
+@end example
+
+Le '?' indique un fichier dans une répertoire qui n'est pas géré par le
+système de contrôle de version. Vous pouvez voir @emph{exactement} toutes
+les modifications faites avec la commande @command{svn diff} sans
+arguments, qui affiche les modifications de fichier dans le format
+"unified diff".
+
+@example
+$ svn diff
+Index: ./bar.c
+===================================================================
+--- ./bar.c
++++ ./bar.c Mon Jul 15 17:58:18 2002
+@@ -1,7 +1,12 @@
++#include <sys/types.h>
++#include <sys/stat.h>
++#include <unistd.h>
++
++#include <stdio.h>
+
+ int main(void) @{
+- printf("Sixty-four slices of American Cheese...\n");
++ printf("Sixty-five slices of American Cheese...\n");
+ return 0;
+ @}
+
+Index: ./README
+===================================================================
+--- ./README
++++ ./README Mon Jul 15 17:58:18 2002
+@@ -193,3 +193,4 @@
++Note to self: pick up laundry.
+
+Index: ./stuff/fish.c
+===================================================================
+--- ./stuff/fish.c
++++ ./stuff/fish.c Mon Jul 15 17:58:18 2002
+-Welcome to the file known as 'fish'.
+-Information on fish will be here soon.
+
+Index: ./stuff/things/bloo.h
+===================================================================
+--- ./stuff/things/bloo.h
++++ ./stuff/things/bloo.h Mon Jul 15 17:58:18 2002
++Here is a new file to describe
++things about bloo.
+@end example
+
+la commande @command{svn diff} génère ce résultat en comparant votre copie
+de travail avec la référence dans @file{.svn}. Les fichier programmés pour
+l'ajout sont affichés avec tout leur contenu en ajout, les fichiers pour
+la suppression sont affiché avec tout leur contenu en suppression.
+
+Maintenant supposons que vous voyez cette affichage et réalisez que vos
+modifications à @file{README} sont érronées; peut-être avez-vous éditer
+le mauvais fichier.
+
+La commande @command{svn revert} répond à ce type de problème. Elle
+supprime tous les modifications.
+
+
+@example
+$ svn revert README
+Reverted ./README
+@end example
+
+Le fichier est ramener a son état avant modification en l'écrasant avec la
+copie de référence de @file{.svn}. Remarquer aussi que @command{svn
+revert} peut annuler toutes opérations programmées -- Dans le cas où vous
+décidez que vous ne voulez pas ajouter un nouveau fichier, ou que vous ne
+voulez pas supprimer un fichier.
+
+Dernier point, ces trois commandes (@command{svn status}, @command{svn
+diff}, @command{svn revert}) peuvent être utilisées sans accès réseau
+(sauf @command{svn status -u}). Ceci facilite la gestion de vos
+modifications en cour lorsque vous voyagez en avion ...
+
+@subsection Fusionner les modifications des autres (résolution de conflit)
+
+Vous avez vu comment la commande @command{svn status -u} peut vous aider
+a déterminer les risques de conflit. Supposons que vous lancez
+@command{svn update} et quelque chose d'intéressant se produit:
+
+@example
+$ svn up
+U ./INSTALL
+G ./README
+C ./bar.c
+@end example
+
+Le codes U et G ne nous intéressent pas ici; ces fichiers ont proprement
+intégrés les changements du dépôt.
+
+Le code 'C' signifie que nous somme en présence d'un conflit. Les conflits
+ont lieu lorsque les modifications du dépôt recouvrent les votres. Ce
+problème doit être résolu manuellement.
+
+Lorsqu'un conflit arrive:
+
+@itemize @bullet
+@item
+Un 'C' est affiché durant la mise à jour et Subversion mémorise que le
+fichier est en ``conflit''.
+@item
+Trois fichiers dont le nom débute par @file{tmp} sont créés; ces fichiers
+sont les originaux des fichiers qui ne peuvent pas être fusionnés
+ensemble.
+@item
+Des marqueurs de conflit sont placés dans les fichier pour repérer les
+zones de recouvrement.
+@end itemize
+
+Dans cette situation, Subversion @emph{ne} vous permet @emph{pas} de
+remonter le fichier tant que les trois fichiers temporaire n'on pas été
+supprimés.
+
+Si vous obtenez un conflit, vous devez soit (1) faire la fusion
+manuellement des textes en conflits (en examinant et en éditant les
+marqueurs de conflit dans le fichier), (2) copier un des fichiers tmp*
+en haut de votre fichier de travail, ou (3) exécuter @command{svn revert}
+pour perdre tous vos modifications.
+
+Une fois que vous avez résolu les conflits, vous devez en informer
+Subversion en supprimant les trois fichiers tmp*. La commande
+@command{svn resolve} est un racourçi qui ne fait rien sinon supprimer les
+trois fichiers tmp* pour vous. Lorsque les fichiers tmp* sont supprimés
+Subversion ne considère plus le fichier en état de conflit.
+
+
+@subsection Remonter vos modifications
+
+Enfin! vos éditions sont finies, vous avez fusionné tous les mise à jour
+du serveur et vous êtes prêt à remonter vos modifications.
+
+La commande @command{svn commit} envoie tous de vos modifications au
+dépôt. Lorsque vous remontez une modification, vous devez fournir une
+@dfn{description des modifications}. Votre description restera attachée à
+la nouvelle révision que vous avez créé.
+
+@example
+$ svn commit -m "Added include lines and corrected # of cheese slices."
+Sending bar.c
+Transmitting file data .
+Committed revision 3.
+$
+@end example
+
+Une autre façon de spécifier une description des modifications est de
+les mettre dans un fichier et de fournir le nom du fichier avec
+l'option @samp{-F}. Si la description des modifications n'a pu être
+fournie avec les options @samp{-m} ou @samp{-F}, alors Subversion
+lancera automatiquement l'éditeur spécifié par la variable d'environnement
+@samp{$EDITOR} pour que vous composiez la description des modifications.
+
+Le dêpot ne s'occupe pas de savoir si vos modifications sont cohérentes ou
+non. Il vérifie uniquement que personne d'autre n'a changé aucun des
+fichiers que vous remontez depuis la dernière fois que vous les avez
+sortie (@command{svn co}) ou mise à jour (@command{svn update}). Si
+quelqu'un l'a fait, toute la remontée achoue avec un message indiquant que
+un ou plusieurs de vos fichiers sont dépassés. Il vous faut lancer
+@command{svn upade}, traiter tous les fusions ou conflits qu'il en résulte
+et recommencer votre remontée.
+
+Nous avons couvert les commandes les plus fondamentales pour travailler
+avec Subversion. Vous pouvez exécuter @command{svn help <nom de la
+commande>} pour avoir une aide sur toute les commandes présentées dans
+cette section.
+
+
+@c ------------------------------------------------------------------
+@node Historique
+@section Historique
+
+Le dépôt trace toutes les remontées et vous permet d'explorer cet
+historique.
+
+Il y a deux commandes qui extraient les informations relatives à
+l'historique de votre depôt. @command{svn log} vous montre des
+informations globales de l'historique: les descriptions de modification
+attachées à chaque révision et quels fichiers/répertoires ont changé pour
+chaque révision. La commande @command{svn diff} est elle plus "précise".
+Elle vous montre les modifications apportées à un fichier dans le temps.
+
+@subsection svn log
+
+Pour avoir des imformations de l'historique d'un fichier ou d'un
+répertoire, vous utilisez la commande @command{svn log}. @command{svn log}
+vous dira qui a modifié le fichier, à quel révision, l'heure et la date de
+la révision et la description des modifications qui a accompagné la
+remontée.
+
+@example
+$ svn log
+------------------------------------------------------------------------
+rev 3: fitz | Mon, 15 Jul 2002 18:03:46 -0500 | 1 line
+
+Added include lines and corrected # of cheese slices.
+------------------------------------------------------------------------
+rev 2: someguy | Mon, 15 Jul 2002 17:47:57 -0500 | 1 line
+
+Added main() methods.
+------------------------------------------------------------------------
+rev 1: fitz | Mon, 15 Jul 2002 17:40:08 -0500 | 2 lines
+
+Initial import
+------------------------------------------------------------------------
+@end example
+
+Remarquez que les descriptions des modifications sont affichées dans
+l'ordre chronologique inversé. Vous pouvez restreindre l'affichage à une
+plage de révision ou à un révision uniquement. Pour celà, utilisé l'option
+@samp{--revision} (@samp{-r}) :
+
+@example
+$ svn log -r 5:19
+[...]
+$ svn log -r 8
+[...]
+@end example
+
+Vous pouvez aussi examiner l'historique des descriptions de modification
+pour un unique fichier ou répertoire en spécifiant le chemin:
+@example
+$ svn log foo.c
+[...]
+$ svn log http://foo.com/svn/trunk/code/foo.c
+[...]
+@end example
+
+les commandes affichent les descriptions de modification uniquement pour
+les révisions où le fichier/répertoire (ou l'URL) a changé.
+
+La commande @command{svn log} a l'option @samp{--verbose} (@samp{-v})
+aussi. Avec cette option, la liste des fichiers/répertoires modifiés
+est également incluse pour chaque révision:
+
+@example
+$ svn log -r 8 -v
+------------------------------------------------------------------------
+rev 8: jrandom | 2002-07-14 08:15:29 -0500 | 1 line
+Changed paths:
+ U /trunk/code/foo.c
+ U /trunk/code/bar.h
+ A /trunk/code/doc/README
+
+Frozzled the sub-space winch.
+
+------------------------------------------------------------------------
+@end example
+
+@subsection svn diff
+
+Nous avons déjà vu la commande @command{svn diff} dans la section
+précédante. Elle affiche les différences d'un fichier dans le format
+"unified diff". Il y a peu, nous l'avons utilisé pour montrer les
+modifications locales réalisées à notre copie de travail.
+
+En fait, il y a @emph{trois} utilisations distinctes de la commande
+@command{svn diff}:
+
+@subsubsection Examiner les modifications locales
+Exécuter @command{svn diff} sans option compare vos fichiers de travail
+avec les versions de référence cachées dans espace @file{.svn}.
+
+@example
+$ svn diff foo
+Index: ./foo
+===================================================================
+--- ./foo
++++ ./foo Tue Jul 16 15:19:53 2002
+@@ -1 +1,2 @@
+ An early version of the file
++...extra edits
+@end example
+
+@subsubsection Comparaison de la copie de travail avec le dépôt
+Si option @samp{--revision}(@samp{-r}), suivi d'un numéros de révision,
+est passé, alors votre copie de travail est comparée à une révision
+particuliaire du dépôt.
+
+@example
+$ svn diff -r 3 foo
+Index: ./foo
+===================================================================
+--- ./foo
++++ ./foo Tue Jul 16 15:19:53 2002
+@@ -1,2 +1,2 @@
+ An early version of the file
+-Second version of the file
++...extra edits
+@end example
+
+@subsubsection Comparaison dépôt dépôt
+Si deux numéros de révision sont passés à @samp{-r}, alors les
+deux révisions (du dépôt) sont directement comparées.
+
+@example
+$ svn diff -r 2:3 foo
+
+Index: ./foo
+===================================================================
+--- ./foo
++++ tmp.280.00001 Tue Jul 16 15:22:19 2002
+@@ -1 +1,2 @@
+ An early version of the file
++Second version of the file
+@end example
+
+
+Si vous lisez l'aide incluse dans svn (@command{svn help diff}), vous
+découvrirez que vous pouvez également fournir une URL au-lieu de votre
+copie de travail. C'est particuliairement appréciable pour inspecter des
+modifications alors que vous n'avez pas de copie de travail disponible:
+
+@example
+$ svn diff -r 23:24 http://foo.com/some/project
+[...]
+@end example
+
+
+@c ------------------------------------------------------------------
+@node Branche et Etiquetage
+@section Branche et Etiquetage
+
+@subsection Branchement avec @command{svn cp}
+
+Ici, vous devez avoir compris comment chaques remontées crées une
+nouvelle et complète arborescence dans le dépôt. Si ce n'est pas le cas,
+lisez ce qui est relavitif aux @dfn{révisions}, @xref{Transactions et
+numéro de révision}, ou @xref{Les numéros de révision sont différents
+maintenant}.
+
+Comme vous le suspectez, le système de fichier (du dépôt) ne grossit
+pas de 652 nouveaux fichier/répertoire à chaque fois qu'une nouvelle
+révision est crée. Au-lieu de çà, chaque nouvelle arborescence est faite
+principalement de pointeurs sur des fichiers/répertoires déjà existant.
+Un nouveaux noeud est créé uniquement lorqu'un élément est modifié, tout
+le reste de la révision utilise un espace de stockage partagé avec
+d'autres révisions d'arborescence. Cette technique montre que le système
+de fichier du dépôt est capable de faire des copies "bon marchées" (en
+espace disque). Ces copies bon marchées ne sont rien d'autre qu'un entrée
+de répertoire pointant sur un fichier existant (un peu comme le fait la
+commande @command{ln} sous Unix). Ce principe est la base de l'étiquetage
+et des branchements.
+
+Supposons que nous avons un dépôt dont la révision de tête (la plus
+récente) est 82. Dans ce dépôt il y a un sous-répertoire @file{mooIRC} qui
+contient un projet de logiciel prêt à être étiqueté. Comment allons nous
+l'étiqueter? Très simple: nous faisons une copie bon marchée de ce
+répertoire. En d'autres mots, nous créons un nouveau répertoire (quelque
+part ailleur dans le système de fichier) qui pointe sur ce noeud
+@emph{spécifique} qui représente le répertoire @file{mooIRC} à la
+révision 82. Bien sûr, vous pouvez nommer ce nouveau répertoire comme bon
+vous semble (probablement quelque chose comme @file{mooIRC-beta}).
+
+La façon la plus simple de faire cette copie est avec la commande
+@command{svn cp} qui peut également opérer uniquement sur des URL. Ainsi
+cette copie peut avoir lieu uniquement côté serveur:
+
+@example
+$ svn cp http://foo.com/repos/mooIRC \
+ http://foo.com/repos/mooIRC-beta
+Committed revision 83.
+@end example
+
+Maintenant, aussi longtemps que vous ne modifié pas le contenu de ce
+répertoire @file{mooIRC-beta}, cette entrée pointera toujours sur le noeud
+qui représente @file{mooIRC} au moment de la création de
+@file{mooIRC-beta} (c'est à dire la révision 82). Ceci est un étiquetage.
+
+Mais qu'en est-il si vous commencez des remontées dans @file{monIRC-beta}?
+Et qu'en est-il si vous continuez à faire des remontées dans l'original
+répertoire @file{mooIRC}? Ainsi, vous avez deux répertoires au début
+identique -- leurs ancêtre commun est @file{mooIRC} dans la révision 82
+-- mais qui maintenant divergent dans le temps par leur contenu. En
+d'autres mots, ils representent différentes @dfn{branches} de votre
+projet.
+
+Il est très important de remarquer que le système de fichier de Subversion
+n'a aucune "conscience" des "étiquetages" ou "branches". Il ne considère
+que les répertoires et tous les répertoires sont égaux. Le concept
+d'étiquetage et de branche attaché à un répertoire particulier n'ont qu'un
+sens @emph{humain}.
+
+C'est pour cette raison qu'il est de la responsabilité de l'utilisateur
+(et de l'administrateur du dépôt Subversion) de choisir de bonnes rêgles
+de nommage pour distinguer les branches, étiquetages...
+Par exemple, voici une bonne organisation possible de votre dépôt:
+
+@example
+ /
+ /projectA
+ /projectA/trunk/
+ /projectA/branches/
+ /projectA/tags/
+ /projectB
+ /projectB/trunk/
+ /projectB/branches/
+ /projectB/tags/
+@end example
+
+Chaque fois que @file{/projectA/trunk} atteind un état étiquetable, faites
+une copie du répertoire quelque part dans @file{/projectA/tags/} et mettez
+la copie en lecture seule. Utiliser la même procédure pour créer une branche
+dans @file{/projectA/branches}.
+
+Voici une autre bonne organisation possible:
+
+@example
+ /
+ /trunk
+ /trunk/projectA
+ /trunk/projectB
+ /branches
+ /branches/projectA
+ /branches/projectB
+ /tags
+ /tags/projectA
+ /tags/projectB
+@end example
+
+Ou, bien sûr, vous pouvez également mettre chaque projet dans un dépôt
+dédié. Ceci est de votre responsabilité. D'autres informations ici:
+@xref{FAQ}.
+
+@subsection Basculer vers une branche avec @command{svn switch}
+
+La commande @command{svn switch} vous permet de ``déplacer'' certaine
+partie ou tout votre copie de travail vers une branche ou une étiquette.
+Par exemple, supposons que j'ai une copie de travail de @file{mooIRC},
+et que je veux travailler sur un sous-système tel qu'il apparait dans
+un sous-répertoire de @file{mooIRC-beta}. En même temps, je veux que
+le reste de ma copie de travail reste sur sa branche d'origine
+@file{mooIRC}. Pour le faire, je bascule le sous-répertoire approprié
+vers le point de la nouvelle branche.
+
+@example
+$ svn switch mooIRC/subsystems/renderer \
+ http://foo.com/repos/mooIRC-beta/subsystems/renderer
+
+U mooIRC/subsystems/renderer/foo.c
+U mooIRC/subsystems/renderer/bar.h
+U mooIRC/subsystems/renderer/baz.c
+@end example
+
+Maintenant mon sous-répertoire @file{renderer} de ma copie de travail
+représente un répertoire différent sur le serveur.
+
+En fait, @command{svn swith} est une version plus "rigolote" de
+@command{svn update}. Alors que @command{svn update} a la possibilité de
+déplacer votre copie de travail dans le temps (en mettant à jour à la
+dernière révision, ou en allant à la révision spécifiée avec l'option
+@samp{-r}), @command{svn switch} est capable de déplacer votre copie de
+travail dans le temps @emph{et} l'espace.
+
+@subsection Déplacer des modifications avec @command{svn merge}
+
+Supposons qu'une équipe de programmeur travaillant sur la branche
+@file{mooIRC-beta} a corrigé un bug critique, et que l'équipe travaillant
+sur la branche @file{mooIRC} originale veut appliquer ces modifications
+également.
+
+La commande @command{svn merge} répond à cette situation. Vous pouvez
+penser à @command{svn merge} comme un cas spécial de @command{svn diff};
+simplement, au-lieu d'affiche un "unified diff" à l'écran, il
+@emph{applique} les modifications à votre copie de travail. Ces nouvelles
+modifications sont locales à votre copie de travail.
+
+Par exemple, supposons que la correction du bug soit arrivé à la remontée
+de la révision 102 de la branche @file{mooIRC-beto}.
+
+@example
+$ svn diff -r 101:102 http://foo.com/repos/mooIRC-beta
+
+[...] # diffs sent to screen
+
+$ svn merge -r 101:102 http://foo.com/repos/mooIRC-beta mooIRC
+U mooIRC/glorb.c
+U mooIRC/src/floo.h
+@end example
+
+Alors que l'affichage de @command{svn merge} est similaire à
+@command{update} ou @command{switch}, La commande n'applique que des
+modifications temporaires à vos fichiers de travail. Une fois que les
+différences sont appliquées comme des modifications locales, vous pouvez
+les examiner comme d'habitude avec @command{svn diff},
+@command{svn status}, ou les annuler comme d'habitude avec @command{svn
+revert}. Si les changement sont acceptable, vous pouvez les remonter.
+
+@subsection Revenir en arrière avec @command{svn merge}
+
+Une autre utilisation courante de @command{svn merge} est pour revenir
+en arrière sur une modification qui a été remontée. C'est-à-dire que vous
+avez remonté des modifications dans la révision 10, et que plus tard vous
+décidez qui y a une erreur. Vous pouvez facilement ramener l'arborescence
+à l'état de la révision 9 avec la commande @command{svn merge}.
+
+@example
+$ svn commit -m "change some stuff"
+Sending bar.c
+Sending foo.c
+Transmitting file data ..
+Committed revision 10.
+$
+
+[...] # le développeur continu et réalise qu'il y a une erreur
+
+$ svn merge -r 10:9 .
+U ./bar.c
+U ./foo.c
+$ svn commit -m "oops, reverting revision 10"
+Sending bar.c
+Sending foo.c
+Transmitting file data ..
+Committed revision 11.
+@end example
+
+Si vous n'êtes pas revenu en arrière sur les modifications dans votre
+répertoire courant (C'est-à-dire que vous voulez revenir en arrière pour
+un fichier spécifique, ou tous les fichiers d'un répertoire spécifique),
+alors la syntaxe est légèrement différente, parce que vous devez dire à
+@command{svn merge} où il doit fusionner les modifications.
+
+@example
+$ svn merge -r 10:9 baz/ baz/
+U ./baz/bar.c
+U ./baz/foo.c
+$ svn commit -m "reverting revision 10's changes in baz/"
+Sending baz/bar.c
+Sending baz/foo.c
+Transmitting file data ..
+Committed revision 12.
+$
+
+[...] # le développeur continu et réalise qu'il y a une erreur
+
+$ svn merge -r 13:12 baz/foo.c baz/foo.c
+U ./baz/foo.c
+$ svn commit -m "reverting revision 12's change to foo.c"
+Sending baz/foo.c
+Transmitting file data .
+Committed revision 15.
+@end example
+
+Conservez à l'esprit que revenir en arrière sur des modifications avec
+cette méthode est comme toutes les autres opérations avec @command{svn
+merge}, ainsi vous devriez utiliser @command{svn status} et @command{svn
+diff} pour confirmer que votre travail est dans l'état que vous voulez
+qu'il soit, et puis utiliser @command{svn commit} pour envoyer la version
+finale au dépôt.
+
+@subsection Suppression de branche ou d'étiquette avec @command{svn rm}
+
+La commande @command{svn rm} peut opérer sur des URL. Un fichier ou un
+répertoire peut-être supprimé du dépôt à ``distance'' sans la présence
+d'une copie de travail:
+
+@example
+$ svn rm http://foo.com/repos/tags/mooIRC-bad-tag -m "deleting bad tag"
+Committed revision 1023.
+@end example
+
+Bien sûr, c'est une forme de remontée immédiate, ainsi une description
+des modifications est requise (@samp{-m}).
+
+
+@c ------------------------------------------------------------------
+@node Propriétés
+@section Propriétés
+
+Subversion vous permet d'attacher n'importe quelle ``Méta-donnée'' à un
+fichier ou un répertoire. Nous appèlerons ces données des @dfn{propriétés}
+et elles peuvent être vues comme un ensemble de paire nom/valeur attaché à
+chaque élément dans votre copie de travail.
+
+Pour mettre ou récupérer une propriété d'un fichier ou d'un répertoire,
+utilisez les commandes @command{svn propset} et @command{svn propget}.
+Pour lister tous les propriétés d'un élément, utilisez @command{svn
+proplist}. Pour supprimer une propriété, utilisez @command{svn propdel}.
+
+@example
+$ svn propset color green foo.c
+property `color' set on 'foo.c'
+
+$ svn propget color foo.c
+green
+
+$ svn propset height "5 feet" foo.c
+property `height' set on 'foo.c'
+
+$ svn proplist foo.c
+Properties on 'foo.c':
+ height
+ color
+
+$ svn proplist foo.c --verbose
+Properties on 'foo.c':
+ height : 5 feet
+ color : green
+
+$ svn propdel color foo.c
+property `color' deleted from 'foo.c'
+@end example
+
+Les propriétés sont @emph{versionnées} comme l'est le contenu des
+fichiers. Ceci signifie que de nouvelles propriétés peuvent être
+fusionnées dans vos fichiers de travail, et peuvent parfois être en
+conflit également. La valeur des propriétés n'est pas obligatoirement du
+texte cependant. Par example, vous pouvez attacher une valeur de
+propriété binaire en utilisant l'option @samp{-F}:
+
+@example
+$ svn propset x-face -F joeface.jpg foo.c
+property `x-face' set on 'foo.c'
+@end example
+
+Subversion founit également une méthode confortable pour éditer
+des propriétés existantes: @command{svn propedit}. Lorsque vous
+exécutez cette commande, Subversion ouvre la valeur de la propriété
+en question dans votre éditeur favori (en fait, l'éditeur que vous
+avez défini avec $EDITOR dans votre interpréteur de commande) et vous
+pouvez éditer la valeur comme n'importe quel fichier texte. Ceci est
+particuliairement agréable pour des propriétés qui sont un tableau de
+valeurs séparés par des retour-chariot (voir plus bas).
+
+Les modifications de propriétés restent considérées comme des
+``modifications locales'' et ne sont pas permanentes tant que vous ne les
+avez pas remontées. Comme les modifications de texte, les modifications de
+propriétés peuvent être vuess avec @command{svn diff}, @command{svn
+status} et également annulées avec @command{svn revert}:
+
+@example
+$ svn diff
+Property changes on: foo.c
+___________________________________________________________________
+Name: color
+ + green
+
+$ svn status
+_M foo.c
+@end example
+
+Remarquez qu'une seconde colonne est apparue dans l'affichage de
+@command{svn status}; le souligné initial indique que vous n'avez pas
+modifié le contenu du fichier, mais le 'M' signifie que vous avez modifié
+les propriétés. @command{svn status} essaie de cacher la seconde colonne
+des propriétés lorsqu'un élément n'a pas de propriété du tout. C'est un
+choix de conception, pour faciliter les nouveaux utilisateurs à ce
+concept. Lorsque des propriétés sont créées, éditées ou mise à jour sur
+un élément, cette seconde colonne apparait toujours après.
+
+@subsection Propriétés spéciales
+
+Subversion n'a pas de règles particulières à l'égard des propriétés. Elles
+peuvent être utilisées à n'importe quel propos. La seule restriction est
+que Subversion s'est réservé les noms avec le préfixe @samp{svn:} pour son
+propre usage. Un certain nombre de propriétés ``magique'' commence avec ce
+préfixe. Nous traitons de leures caractéristiques ici.
+
+@subsubsection @samp{svn:executable}
+
+C'est une propriété pour les fichiers uniquement et qui peut être mis à
+n'importe quelle valeur. Son existance modifier les permissions du fichier
+pour permettre son exécution.
+
+@subsubsection @samp{svn:mime-type}
+
+Actuellemnt, Subversion examine la propriété "svn:mime-type" pour décider
+si le fichier est de type texte ou binaire. Si le fichier n'a pas de
+propriété "svn:mime-type" ou si la valeur de la propriété correspond à
+"text/*", alors Subversion considère que c'est un fichier texte. Si le
+fichier a la propriété "svn:mime-type" mise à autre chose que "text/*",
+alors le fichier est considéré comme binaire.
+
+Si Subversion considère que le fichier est binaire, il ne tentera pas de
+fusionner durant une mise à jour. Au-lieu de çà, Subversion crée deux
+fichiers dans votre copie de travail (un fichier correspondant au dépôt et
+un autre à votre copie de travail). Celui avec vos modifications locales
+est renommé avec l'extension ".orig".
+
+Subversion aide l'utilisateur en tentant de détecter la présence d'un
+fichier binaire lors d'un 'svn import' ou 'svn add'. Si le fichier est
+considéré comme binaire par ces commandes, elles mettent la propriété
+"svn:mime-type" à "application/octet-stream" au fichier qui vient être
+ajouté. Si Subversion s'est trompé lors de sa détection, vous pouvez
+toujours supprimer ou éditer la propriété.
+
+Enfin, si la propriété "svn:mime-type" est mise, alors mod_dav_svn
+l'utilisera pour remplire l'entête 'Content-type:' lors d'une réponse à
+une requête http GET. Ceci rend l'affichage des fichiers plus agréable
+lors de la consultation d'un dépôt avec un navigateur web.
+
+@subsubsection @samp{svn:ignore}
+
+Si vous attachez cette propriété à un répertoire, les fichiers avec un
+certain motif dans leur nom seront ignorés par @command{svn status}. Par
+exemple, supposons que je ne veux pas voir les fichiers objets ou les
+fichiers de sauvegarde dans le listing de @command{svn status}:
+
+@example
+$ svn status
+M ./foo.c
+? ./foo.o
+? ./foo.c~
+@end example
+
+En utilisant @command{svn propedit}, je peux mettre la valeur de
+@samp{svn:ignore} à une liste de motifs délimités par des retours-chariot:
+
+@example
+$ svn propget svn:ignore .
+*.o
+*~
+@end example
+
+
+@subsubsection @samp{svn:keywords}
+
+Subversion a l'abtitude de substituer certains mots-clé par des chaines de
+caractère utilent dans les fichiers textes. Par exemple, si je place ce
+texte dans un fichier:
+
+@example
+Ceci est le dernier rapport de la ligne de front.
+$LastChangedDate$
+Les comulus sont plus nombreux à l'approche de l'été.
+@end example
+
+Subversion est capable de substituer la chaine @samp{$LastChangedDate$}
+avec l'actuelle date de dernière modification du fichier.
+
+@example
+Ceci est le dernier rapport de la ligne de front.
+$LastChangedDate: 2002-07-15T03:53:48 $
+Les comulus sont plus nombreux à l'approche de l'été.
+@end example
+
+Il y a quatre mots-clé que Subversion sait comment substituer:
+
+@table @b
+@item LastChangedDate
+La dernier date quand le fichier a été modifié. L'abbréviation 'Date'
+peut-être utilisée.
+@item LastChangedRev
+La dernière révision quand le fichier a été modifié. L'abbréviation 'Rev'
+peut-être utilisée.
+@item LastChangedBy
+Le dernier utilisateur qui a changé le fichier. L'abbréviation 'Author'
+peut-être utilisée.
+@item HeadURL
+L'URL complète de la dernière version du fichier dans le depôt.
+L'abbréviation 'URL' peut-être utilisée.
+@end table
+
+Pour activer un mot-clé ou fixer un mot-clé, vous avez simplement besoin
+de mettre la propriété @samp{svn:keywords} à une liste de mot-clé:
+
+@example
+$ svn propset svn:keywords "Date Author" foo.c
+property `svn:keywords' set on 'foo.c'
+@end example
+
+Lorsque que vous remonterez ces changements de propriété, vous découvrirez
+que toutes les occurrences de @samp{$Date$}, @samp{$LastChangedDate$},
+@samp{$Author$}, et @samp{$LastChangedBy$} auront leurs valeurs de
+substitutions dans @file{foo.c}.
+
+@subsubsection @samp{svn:eol-style}
+
+Par défaut, Subversion ne prête pas attention aux fins de ligne. Si un
+fichier texte a LF, CR or CRLF pour fins de ligne, alors celles-ci sont
+les fins de ligne qui existeront dans le fichier pour le dépôt et la copie
+de travail.
+
+Mais si les développeurs travaillent sur différentes plateformes, les fins
+de ligne peuvent être la source de nuisances. Par exemple, si un
+développeur sous win32 et un développeur sous Unix modifient l'un après
+l'autre le même fichier, les fins de ligne du fichier changent entre les
+révisions du dépôt. Ceci rend l'examen ou la fusion des différences très
+difficile, car @emph{chaques} lignes apparaissent avoir changé pour chaque
+version du fichier.
+
+La solution ici est de mettre la propriété @samp{svn:eol-style} à
+``native''. Celà permet au fichier d'apparaitre avec les fins de ligne
+``native'' dans chaqu'un des systèmes d'exploitation des développeurs.
+Remarquez, néanmoins, que le fichier est toujours avec des fins de
+ligne LF dans le dépôt. Ceci prévient les problèmes de fin de ligne
+``bidon'' de révision en révision.
+
+Alternativement, vous pouvez forcer un fichier à toujours conserver une
+convention de fin de ligne spécifique : mettez la propriété
+@samp{svn:eol-style} d'un fichier à @samp{LF}, @samp{CR} ou @samp{CRLF}.
+Un fichier '.dsp' de win32 par exemple, qui est utilisé par les outils de
+développement Microsoft, doit toujours avoir des fins de ligne CRLF.
+
+@subsubsection @samp{svn:externals}
+
+@xref{Modules}.
+
+
+@c ------------------------------------------------------------------
+@node Modules
+@section Modules
+
+Parfois il est utile de construire une copie de travail qui est faite de
+différentes sorties. Par exemple, vous voulez que différents
+sous-répertoires correspondent à différents endroits du dépôt.
+
+Une méthode possible est de commencer par une sortie d'une copie de
+travail puis d'exécuter @command{svn switch} dans différents
+sous-répertoires. Mais c'est du boulot. Ne serait-il pas agréable de
+définir -- en un seul lieu -- exactement comment vous voulez que la copie
+de travail soit?
+
+Ceci est connu en tant que @dfn{module}. vous pouvez définir un module en
+attachant une autre propriété ``magique'' à un répertoire: la propriété
+@samp{svn:externals}.
+
+@example
+$ svn propget svn:externals projectdir
+subdir1/foo http://url.for.external.source/foo
+subdir1/bar http://blah.blah.blah/repositories/theirproj
+subdir1/bar/baz http://blorg.blorg.blorg/basement/code
+@end example
+
+En considérant que cette propriété est attachée au répertoire
+@file{projectdir}, alors lorsque vous faite une sortie, vous obtenez aussi
+ce qui est défini par la propriété.
+
+@example
+$ svn checkout http://foo.com/repos/projectdir
+A projectdir/blah.c
+A projectdir/gloo.c
+A projectdir/trout.h
+Checked out revision 128.
+
+Fetching external item into projectdir/subdir1/foo
+A projectdir/subdir1/foo/rho.txt
+A projectdir/subdir1/foo/pi.txt
+A projectdir/subdir1/foo/tau.doc
+Checked out revision 128.
+[...]
+@end example
+
+En modifiant la valeur de la propriété de @samp{svn:externals}, la
+définition du module peut changer dans le temps et les appels suivants à
+@command{svn update} mettront à jour votre copie de travail de façon
+approprié.
+
+@c ### Karl, anything else to add here? I'm suspicious that this
+@c feature doesn't work as I expect just yet; when I run 'svn up' at
+@c the top of the wc, nothing happens in the external directory at
+@c all, because (I guess) it's not linked to the parent.
+
+
+@c ------------------------------------------------------------------
+@node Autres commandes
+@section Autres commandes
+
+@subheading @command{svn cleanup}
+
+Lorsque Subversion modifie votre copie de travail (ou toutes informations
+à l'intérieur de @file{.svn/}), il essaie de la faire de la façon la plus
+sûre possible. Avant toute modification, il écrit ces intentions dans un
+un "logfile", puis exécute les commandes du "logfile". C'est similaire
+dans la conception à un système de fichier journalisé; si l'utilisateur
+fait Contrôle-C ou si la machine se plante, le "logfile" reste. En
+réexécutant les "logfiles", le travail peut être terminé, et votre copie
+de travail peut revenir à un état consistant.
+
+Et c'est exactement ce que fait @command{svn cleanup}: il recherche
+dans votre copie de travail des "logfile" que sont restés et les
+réexécute, supprimant ainsi les verrous dans le processus. Utilisez cette
+commande si Subversion vous dit que certaines parties de votre copie de
+travail sont ``verrouillées''. Enfin, @command{svn status} affichera un
+'L' a côté des éléments verrouillés.
+
+@example
+$ svn st
+ L ./somedir
+M ./somedir/foo.c
+
+$ svn cleanup
+$ svn st
+M ./somedir/foo.c
+@end example
+
+@subheading @command{svn info}
+
+En général nous essayons de décourager les utilisateurs de lire
+directement le fichier @file{.svn/entries} utilisé pour tracer les
+éléments. Au lieu de celà, les curiosités peuvent être "calmées" en
+utilisant la command @command{svn info} qui affiche la plupart des
+informations tracées :
+
+@example
+$ svn info client.texi
+Path: client.texi
+Name: client.texi
+Url: http://svn.collab.net/repos/svn/trunk/doc/handbook/client.texi
+Revision: 2548
+Node Kind: file
+Schedule: normal
+Last Changed Author: fitz
+Last Changed Rev: 2545
+Last Changed Date: 2002-07-15 23:03:54 -0500 (Mon, 15 Jul 2002)
+Text Last Updated: 2002-07-16 08:48:04 -0500 (Tue, 16 Jul 2002)
+Properties Last Updated: 2002-07-16 08:48:03 -0500 (Tue, 16 Jul 2002)
+Checksum: 8sfaU+5dqyOgkhuSdyxGrQ==
+@end example
+
+
+@subheading @command{svn import}
+
+La commande import est un moyen rapide de remonter une arborescence de
+fichiers non versionnée dans un dépôt.
+
+Il y a deux façon d'utiliser cette commande:
+
+@example
+$ svnadmin create /usr/local/svn/newrepos
+$ svn import file:///usr/local/svn/newrepos mytree
+Adding mytree/foo.c
+Adding mytree/bar.c
+Adding mytree/subdir
+Adding mytree/subdir/quux.h
+Transmitting file data....
+Committed revision 1.
+@end example
+
+L'exemple précédent place le contenu du répertoire @file{mytree}
+directement à la racine du dépôt:
+
+@example
+/foo.c
+/bar.c
+/subdir
+/subdir/quux.h
+@end example
+
+Si vous donnez un troisième argument à la commande @command{svn import},
+il utilisera l'argument comme le nom du nouveau sous-répertoire à créer
+dans l'URL.
+
+@example
+$ svnadmin create /usr/local/svn/newrepos
+$ svn import file:///usr/local/svn/newrepos mytree fooproject
+Adding mytree/foo.c
+Adding mytree/bar.c
+Adding mytree/subdir
+Adding mytree/subdir/quux.h
+Transmitting file data....
+Committed revision 1.
+@end example
+
+Le dépôt doit maintenant ressembler à :
+
+@example
+/fooproject/foo.c
+/fooproject/bar.c
+/fooproject/subdir
+/fooproject/subdir/quux.h
+@end example
+
+@subheading @command{svn export}
+
+La commande export est un moyen rapide de créer une arborescence de
+fichier non versionnée d'un répertoire d'un dépôt.
+
+@example
+$ svn export file:///usr/local/svn/newrepos/fooproject
+A fooproject/foo.c
+A fooproject/bar.c
+A fooproject/subdir
+A fooproject/subdir/quux.h
+Checked out revision 3.
+@end example
+
+Le répertoire résultant ne contiendra aucun espace d'administration
+@file{.svn}.
+
+
+@subheading @command{svn mkdir}
+
+C'est un autre commande partique et qui a deux usages.
+
+Premièrement, elle peut être utilisée pour simultanément créer un nouveau
+répertoire dans la copie de travail et le programmé pour l'ajout:
+
+@example
+$ svn mkdir new-dir
+A new-dir
+@end example
+
+Ou, elle peut être utilisée pour instantanément créer un répertoire dans
+le dépôt (aucune copie de travail n'est nécessaire):
+
+@example
+$ svn mkdir file:///usr/local/svn/newrepos/branches -m "made new dir"
+Committed revision 1123.
+@end example
+
+Encore une fois, c'est une forme de remontée immédiate et une description
+de modification est requise.
Property changes on: ./doc/handbook/french/client.texi
___________________________________________________________________
Name: svn:eol-style
+ native
Index: ./doc/handbook/french/repos_admin.texi
===================================================================
--- ./doc/handbook/french/repos_admin.texi
+++ ./doc/handbook/french/repos_admin.texi Tue Jul 23 05:27:55 2002
@@ -0,0 +1,770 @@
+@node Administration des Dépôts
+@chapter Administration des Dépôts
+
+Comment administrer un dépôt Subversion.
+
+Dans cette section, nous nous concentrerons sur comment utiliser les
+programmes @command{svnadmin} et @command{svnlook} pour travailler avec
+des dépôts.
+
+@menu
+* Créer un dépôt::
+* Examiner un dépôt::
+* Accroches d'un dépôt::
+* Maintenance d'un dépôt::
+* Mettre un dépôt sur le réseau::
+* Migrer un dépôt::
+@end menu
+
+
+
+@c ------------------------------------------------------------------
+@node Créer un dépôt
+@section Créer un dépôt
+
+Créer un dépôt est incroyablement simple:
+
+@example
+$ svnadmin create myrepos
+@end example
+
+Ceci crée un nouveau dépôt dans le sous-répertoire @file{myrepos}.
+
+Un nouveau depôt commence toujours sa "vie" à la révision 0, qui est
+défini pour n'être rien saut le répertoire racine (@file{/}).
+
+Comme mentionné dans une section proche (### xref?), les révisions de
+dépôt peuvent avoir des propriétés non versionnées qui lui sont attachées.
+En particulier, chaque révision est créée avec une propriété "date de
+modification" @code{svn:date} (les autres propriétés communes incluent
+@code{svn:author} et @code{svn:log}).
+
+Pour un dépôt nouvellement créé, la révision 0 n'a rien sauf la propriété
+@code{svn:date} attachée.
+
+Voici un arrêt rapide sur l'anatomie d'un dépôt:
+
+@example
+$ ls myrepos
+conf/
+dav/
+db/
+hooks/
+locks/
+@end example
+
+@table @samp
+@item conf
+Actuellement inutilisé; les fichiers de configuration côté dépôt
+arriveront un jour ici.
+@item dav
+Si le dépôt est accédé par Apache et mod_dav_svn, des bases de données
+privées de gestion sont stockées ici.
+@item db
+L'environnement principal de "Berkeley DB", c'est plein de tables DB qui
+comprennent les données stokées par libsvn_fs. C'est ici que toutes vos
+données sont! En particulier, la plupart de vos contenus de fichiers
+arrivent dans la table 'strings'. Les fichiers log s'accumulent aussi ici,
+ainsi les transactions peuvent être récupérées.
+@item hooks
+C'est ici que ce trouve les fichiers de pre- et post-accroche de remonté
+(et un jour, une accroche de lecture).
+@item locks
+Un simple fichier se trouve ici; les lectures et écriveurs prennent un
+vérrou partagé sur ce fichier. Ne pas supprimer ce fichier.
+@end table
+
+Une fois que le dépôt a été créé, il est très probable que vous vouliez
+utiliser le client svn pour importer une arborescence initiale. (essayez
+@command{svn help import}, ou @xref{Autres commandes}.)
+
+
+@c ------------------------------------------------------------------
+@node Examiner un dépôt
+@section Examiner un dépôt
+
+@subsection Transactions et Révisions
+
+Un dépôt Subversion est essentiellement une séquence d'arborescence;
+chaque arborescence est appelée une @dfn{révision}. Si ceci est nouveau
+pour vous, il serait bon que vous lisiez
+@ref{Transactions et numéro de révision}.
+
+Chaque révision commence comme une @dfn{transaction} d'arborescence. Quand
+vous faites une remontée, un client construit une transaction qui copie
+ses modifications locales, et lorsque la remontée a réussie, la
+transaction est effectivement promue en une nouvelle révision
+d'arborescence et un nouveau numéro de révision lui est assigné.
+
+Les mise à jour fonctionnent de façon similaire: le client contruit une
+transaction d'arborescence qui est un "mirroir" de sa copie de travail.
+Le dépôt alors compare la transaction d'arborescence avec une révision de
+l'arborescence, et envoie en retour un delta des arborescences. Lorsque
+la mise à jour est terminée, la transaction est terminée et supprimée du
+dépôt.
+
+L'utilisation de transaction d'arborescence est le seul moyen pour
+'écrire' dans le système de fichier versionné du dépôt; tous les
+utilisateurs de libsvn_fs font çà. Cependant, il est important de
+comprendre que la durée de vie de la transaction est totalement flexible.
+Dans le cas d'une mise à jour, la transaction d'arborescences est
+temporaires et immédiatement détruites. Dans le cas d'une remontée,
+les transactions sont transformées en une révision permanente (ou
+abandonnées si la remontée échoue). Dans le cas d'une erreur ou d'un bug,
+il est possible que la transaction soit accidentellement soit laissée tel
+quel -- l'appelant de libsvn_fs peut mourrir avant de la supprimer. Et en
+théorie, un jour une application de workflow entière pourra faire des
+réparations lors de la creation des transaction; elles pourraient être
+examinées alternativement par différents gestionnaires avant d'être
+supprimées pour promues à une révision.
+
+Le fait est que si vous êtes en train d'administrer un dépôt Subversion,
+vous allez devoir examiner les révisions et les transactions. Celà fait
+partie du travail de suveillance de la bonne santé de votre dépôt.
+
+@subsection svnlook
+
+@command{svnlook} est un outil qui travail en lecture-seule@footnote{
+pourquoi en lecture-seule? parce que si un script d'accroche de
+pré-remonté modifie la transaction avant que la remonté soit faite, la
+copie de travail n'aura aucune moyen pour savoir ce qui c'est passé, et
+serait donc désynchronisé sans le savoir. Subversion n'a actuellement
+aucun moyen pour traiter cette situation, et peut-être ne l'aura jamais.}
+et qui peut-être utilisé pour examiner les révisions et les transactions
+d'arborescences d'un dépôt. Il est utile pour les administrateurs système,
+et peut aussi être utilisé par un script de pre- ou post-remonté.
+
+L'utilisation la plus simple est:
+
+@example
+$ svnlook repos
+@end example
+
+Celà imprime des informations sur la dernière révision dans le dépôt
+"repos". En particulier, elle montrera les descriptions de modification,
+l'auteur, la date, et un diagramme de l'arborescence.
+
+Pour regarder à une révision ou une transaction particulière:
+
+@example
+$ svnlook repos rev 522
+$ svnlook repos txn 340
+@end example
+
+Ou, si vous voulez uniquement voir certains type d'information,
+@command{svnlook} accèpte plusieurs sous-commandes. par exemple:
+
+@example
+$ svnlook repos rev 522 log
+$ svnlook repos rev 559 diff
+@end example
+
+Les sous-commandes disponibles sont:
+
+@table @samp
+@item log
+Affiche la description des modifications de l'aborescence.
+@item author
+Affiche l'auteur de l'arborescence.
+@item date
+Affiche la date de l'arborescence.
+@item dirs-changed
+Affiche la liste des répertoires qui ont changé dans l'arborescence.
+@item changed
+Affiche la liste de tous les fichiers et répertoires qui ont changé dans
+l'arborescence.
+@item diff
+Affiche un "unified diff" des fichiers modifiés.
+@end table
+
+
+@subsection l'interpréteur de commande
+
+L'outil @command{svnadmin} a un mode avec un interpréteur de commande
+'jouet'. Il n'en fait pas beaucoup, mais il permet de "fourrager" dans le
+le dépôt comme s'il y avait une mountage de système de fichier imaginaire.
+Les commandes de base @command{cd}, @command{ls}, @command{exit}, et
+@command{help} sont disponibles, aussi bien que la très spéciale commande
+@command{cr} -- "changer de révision". La dernière commande vous permet de
+vous déplacer entre révisions d'arborescence.
+
+@example
+$ svnadmin shell repos
+<609: />$
+<609: />$ ls
+ < 1.0.2i7> [ 601] 1 0 trunk/
+ <nh.0.2i9> [ 588] 0 0 branches/
+ <jz.0.18c> [ 596] 0 0 tags/
+
+<609: />$ cd trunk
+<609: /trunk>$ cr 500
+<500: /trunk>$ ls
+ < 2.0.1> [ 1] 0 3462 svn_config.dsp
+ < 4.0.dj> [ 487] 0 3856 PORTING
+ < 3.0.cr> [ 459] 0 7886 Makefile.in
+ < d.0.ds> [ 496] 0 9736 build.conf
+ < 5.0.d9> [ 477] 1 0 ac-helpers/
+ < y.0.1> [ 1] 0 1805 subversion.dsp
+[...]
+<500: />$ exit
+@end example
+
+L'affichage de @command{ls} a seulement quelques colonnes:
+
+@example
+ NODE-ID CREATED-REV HAS_PROPS? SIZE NAME
+
+ < 1.0.2i7> [ 601] 1 0 trunk/
+ <nh.0.2i9> [ 588] 0 0 branches/
+ <jz.0.18c> [ 596] 0 0 tags/
+@end example
+
+
+@c ------------------------------------------------------------------
+@node Accroches d'un dépôt
+@section Accroches d'un dépôt
+
+Une @dfn{accroche} est un programme déclenché par un accès en lecture ou
+écriture au dépôt. L'accoche reçoie suffisament d'information pour dire
+quel est l'action, la/les cibles de l'opération, et qui le fait. En
+fonction de la sortie ou du code de retour de l'accroche, le programme
+d'accroche peut continuer l'action, la stopper, ou la suspendre
+d'une certaine manière.
+
+Les accroches de Subversion sont des programme qui résident dans le
+répertoire @file{hooks/} du dépôt:
+
+@example
+$ ls repos/hooks/
+post-commit.tmpl* read-sentinels.tmpl write-sentinels.tmpl
+pre-commit.tmpl* start-commit.tmpl*
+@end example
+
+C'est ainsi que le répertoire 'hooks' apparait après la création d'un
+dépôt. Il ne contient aucun programmes d'accroche -- ce ne sont que des
+modèles.
+
+Les accroches actuelles doivent être nommées `start-commit', `pre-commit'
+ou `post-commit'. Les fichiers modèles (.tmpl) sont des exemples de
+script shell pour vous aider à commencer; lisez les pour connaitre les
+détails de fonctionnement de chaque accroche. Pour faire vos propre
+accroche, copié `foo.tmpl' en `foo' et éditez le.
+
+Les `read-sentinels' et `write-sentinels' ne sont pas encore implémentés.
+Leurs intentions est d'offrir un fonctionnement plus proche du démon que
+des accroches. Une sentinelle (Ndt: c'est la bonne traduction ?) est
+démarré au début d'une opération utilisateur. Le serveur Subversion
+commnunique avec la sentinelle en utilisant un protocole encore a définir.
+En fonction de la réponse de la sentinelle, Subversion va peut-être
+stopper ou modifier l'opération.
+
+Voici une description des programmes d'accroche:
+
+@table @samp
+
+@item start-commit
+Le programme est exécuté avant que la transaction de remonté soit créée.
+C'est typiquement utilisé pour décider si l'utilisateur à les privilèges
+de remonter des modifications dans le dépôt. Le dépôt passe deux arguments
+à ce programme: le chemin vers le dépôt, et le nom de l'utilisateur qui
+tente la remontée. Si le programme retourne un code de sortie différent de
+zéro, la remontée est stoppée avant que la transaction ne soit créée.
+@item pre-commit
+Ce programme est exécuter quand la transaction est complète, mais avant
+quelle soit validée. Typiquement, cette accroche est utilisée pour
+protéger contre des remontées qui ne sont pas authorisées à cause du
+contenu ou du lieu (par exemple, votre site pourrait exiger que toutes
+les remontées à une certaine branche inclues un numéros de ticket du
+système de traçage de bug, ou que la description des modifications
+arrivant soit non vide.)@footnote{Actuellement, c'est la seule méthode
+part laquelle un utilisateur peut implémenter un contrôle d'accès avec une
+granulosité fine; au-delà des facilités offertes pas Apache
+(@file{httpd.conf}). Dans une future version de Subversion, Nous
+planifions d'implémenter une système d'ACL (Liste de Control d'Accès)
+directement dans le système de fichier.} Le dépôt passe deux paramètres à
+ce programme: le chemin vers le dépôt et le nom de la transaction en
+attende de validation. Si le programme retourne un code de sortie
+différente de zéro, la remontée est annulée et la transaction supprimée.
+@item post-commit
+Ce programme est exécuté après que la transation soit réalisée et que nous
+avons une nouvelle révision. La plupart des gens utilise cette accroche
+pour envoyer des emails decrivant la remonté ou pour réaliser une
+sauvegarde à chaud du dépôt. Le dépôt passe deux arguments à ce programme:
+le chemin vers le dépôt et le nouveau numéros de révision qui a été créé.
+Le code de sortie du programme est ignoré.
+@end table
+
+Notez que les accroches doient être exécutable part l'utilisateur qui
+les lance (communément l'utilisateur qui exécute httpd) et que ce même
+utilisateur doit être capable d'accèder au dépôt.
+
+Les accroches pre- et post-remontée ont besoin de connaitre des choses
+a propos des modifications qui vont être remontées (ou qui viennent d'être
+remontée). La solution est un programme indépendant, @command{svnlook}
+(@xref{Examiner un dépôt}.) qui est installé au même endroit que le
+binaire @command{svn}. Le script peut utiliser @command{svnlook} pour
+examiner une transaction ou une révision d'arborescence. Il produit une
+sortie qui est aussi visible par un humain que par un programme, ainsi les
+scripts d'accroche peuvent facilement le parser. Notez que `svnlook'
+travail en lecture-seule -- il ne peut que inspecter et ne peut pas
+modifier le dépôt.
+
+
+@c ------------------------------------------------------------------
+@node Maintenance d'un dépôt
+@section Maintenance d'un dépôt
+
+@subsection Gestion de Berkeley DB
+
+Actuellement, le dépôts de Subversion n'a qu'un moteur de base de données:
+Berkeley DB. Toute votre structure de système de fichier et vos données
+sont dans un ensemble de tables dans @file{repos/db/}.
+
+Berkeley DB est livré avec des outils pour gérer ces fichiers, et ont
+leure propre et excellente documenations. (voir
+@url{http://www.sleepycat.com}, ou lisez juste les pages man.) Nous ne
+couvrirons pas tous ces outils ici; nous mentionnerons quelqu'une des
+procédures les plus communes dont un administrateur de dépôt pourrait
+avoir besoin.
+
+Premièrement, rappelez vous que Berkeley DB a de véritables transactions.
+toutes tentatives de modifications de la DB (Data-Base, Base de Donnée)
+est un premier loggué. Au moindre problème, la DB peut retourner
+d'elle-même en arrière au précédent ``point de contrôle'' et recommencer
+la transaction pour récupérer les données dans le même état.
+
+Selon notre propre expérient, nous avons rencontré des situations ou un
+bug dans Subversion (qui produit un plantage) peut parfois avoir l'effet
+de bord de laisser d'environnement de DB dans un état 'vérouillé'. Les
+tentatives suivantes de lecture ou écriture reste bloquées, en attente sur
+le verrou.
+
+Pour ``débloquer'' le dépôt, utilisez @command{db_recover}:
+
+@example
+$ db_recover -ve -h repos/db
+db_recover: Finding last valid log LSN: file: 40 offset 4080873
+db_recover: Checkpoint at: [40][4080333]
+db_recover: Checkpoint LSN: [40][4080333]
+db_recover: Previous checkpoint: [40][4079793]
+db_recover: Checkpoint at: [40][4079793]
+db_recover: Checkpoint LSN: [40][4079793]
+db_recover: Previous checkpoint: [40][4078761]
+db_recover: Recovery complete at Sun Jul 14 07:15:42 2002
+db_recover: Maximum transaction id 80000000 Recovery checkpoint [40][4080333]
+@end example
+
+Premièrement, assurez vous que vous exécutez cette commande avec le compte
+de la base de donnée et @emph{non} en tant que root. En exécutant
+@command{db_recover} sous le compte root, celà laissera des fichiers avec
+le propriétaire root dans le répertoire db qui ne pourront être ouvert par
+le compte non root qui gère la base de donnée et qui est typiquement le
+compte du processus Apache.
+
+Deuxièmement, un administrateur de dépôt peut avoir besoin de gérer le
+grossissement des fichiers log. A tout instant, l'environnement DB
+utilise au moins un fichier log pour enregistrer la transactions; lorsque
+le ficheir log actuel grossi jusqu'à 10 méga octet, un nouveau fichier log
+est débuté, et l'ancien reste.
+
+Ainsi, après une longue periode, vous constaterez un nombre important de
+fichiers log. A ce moment là, vous avez deux choix : si vous laissez
+tous les fichiers log, vous avez la garantie que @command{db_recorer}
+pourra toujours "rejouer" chaques transactions de la base de donnée,
+depuis la première remontée (ceci est la méthose sûre et un peu
+paranoïaque). L'autre méthode, est de demander à Berkeley DB de vous dire
+quels fichiers log ne sont plus activement utilisés :
+
+@example
+$ db_archive -a -h repos/db
+log.0000000023
+log.0000000024
+log.0000000029
+@end example
+
+Notre dépôt de Subversion utilise une script d'accroche de post-remontée,
+qui après avoir réalisé une sauvegarde à chaud du dépôt, supprime ces
+fichiers log excédentaire. Dans les sources de Subversion, regardez
+@url{tools/backup/hot-backup.py}.
+
+Ce script illustre également une méthode sûre de faire une sauvegarde du
+dépôt alors qu'il reste en cours d'utilisation: copier tout le repertoire
+du dépôt, puis recopier les fichiers log listé par la commande
+@command{db_recorer -l}.
+
+Enfin, noté que Berkeley DB a un système de verrouillage complet; dans des
+cas d'opérations extémement intense de svn, nous avons constaté des
+situations où l'envirennement de DB n'a plus suffisament de verroux. Le
+nombre maximum de verrou peut-être ajusté en changant les valeurs dans
+le fichier @file{repos/db/DB_CONFIG}. Ne changez pas les valeurs par
+défaut sans savoir exactement ce que vous faites; Voyez sûr d'avoir lu
+@url{http://www.sleepycat.com/docs/ref/lock/max.html} en premier.
+
+@subsection Utilisation de svnadmin
+
+L'outil @command{svnadmin} a des sous-commandes qui sont spécifiquement
+utiles à un administrateur de dépôt. Faites attention lorsque vous
+utilisez @command{svnadmin}! @command{svnadmin} contrairement à
+@command{svnlook}, qui ne fonctionne qu'en lecture seule, peut modifier
+le dépôt.
+
+La fonctionnalité la plus utilisée est probablement @command{svadmin
+setlog}. Une description de modification est une propriété unversionnée
+directement attaché à la révision; Il n'y a qu'une seule description de
+modification par révision. Parfois l'utilisateur a remonté sa description
+de modification et il a besoin de la remplacer.
+
+@example
+$ echo "Here is the new, correct log message" > newlog.txt
+$ svnadmin setlog myrepos 388 newlog.txt
+@end example
+
+Il y a un sympathique script CGI dans @file{tools/cgi/} qui permet à
+certain (avec un mot de passe d'accès) de modifier les descriptions de
+message via un navigateur web.
+
+Un autre usage courant de @command{svnadmin} est d'inspecter et de
+nettoyer de vieilles transactions abandonnées. Les remontées et les mises
+à jour créent toutes les deux des transactions d'arborescence, mais
+occasionnellement un bug ou un plantage peut les laisser telles quelles.
+En inspectant la date de la transaction, un administrateur peut decider la
+supprimer.
+
+@example
+$ svnadmin lstxns myrepos
+319
+321
+$ svnadmin lstxns --long myrepos
+Transaction 319
+Created: 2002-07-14T12:57:22.748388Z
+[...]
+$ svnadmin rmtxns myrepos 319 321
+@end example
+
+@c ### Hey guys, are going to continue to support 'svnadmin undeltify'??
+
+Une autre sous-commande très utilisée est @command{svnadmin undeltify}.
+Rappelez vous que la dernière version de chaque fichier est stockée en
+entier dans le dépôt, et les révisions précédentes des fichiers sont
+stockés comme différences par rapport à la révision suivant la plus
+proche. Lorsqu'un utilisateur tente un accès à une révision antérieur, le
+dépôt doit appliquer à rebours les différences au plus récent des contenus
+complet pour obtenir la version antérieur désirée.
+
+Si une révision d'arborescence particulière est très populaire,
+l'administrateur peut améliorer le temps d'accès à cette arborescence en
+``undeltifying'' (supprimer les différences) tous les patches dans la
+révision -- C'est-à-dire en convertissant chaque fichier en contenu
+complet.
+
+@example
+$ svnadmin undeltify myrepos 230 /project/tags/release-1.3
+Undeltifying `/project/tags/release-1.3' in revision 230...done.
+@end example
+
+
+@c ------------------------------------------------------------------
+@node Mettre un dépôt sur le réseau
+@section Mettre un dépôt sur le réseau
+
+Vous avez donc un dépôt et vous voulez le rendre accessible pour tout le
+réseau.
+
+Le serveur réseau primaire de Subversion est httpd d'Apache parlant le
+protocole WebDav/deltaV, qui est un ensemble d'extension à http. Pour plus
+d'information sur DAV, voir @url{http://www.webdav.org}.
+
+Pour rendre votre dépôt accessible depuis le réseau, vous devez
+@itemize @bullet
+@item
+avoir httpd 2.0 fonctionnant avec le module @file{mod_dav}
+@item
+installer le greffon @file{mod_dav_svn} pour mod_dav, qui utilise la
+librairie d'accès au dépôt de Subversion
+@item
+configurer votre fichier @file{httpd.conf} pour exporter le dépôt
+@end itemize
+
+Vous pouvez accomplir les deux premiers en contruisant httpd et Subversion
+depuis les sources ou en installant un paquetage binaire sur votre
+système. Le second appendice de ce document contient plus d'instruction
+détaillées pour le faire. (@xref{Compilation et installation}.) Des
+instructions sont également disponibles dans le fichier @file{INSTALL}
+dans les sources de Subversion.
+
+Dans cette section, nous nous concentrerons sur la configuration de votre
+fichier @file{httpd.conf}.
+
+Quelque part au début de votre fichier de configuration, définissez un
+nouveau bloque @command{Location}:
+
+@example
+<Location /repos>
+ DAV svn
+ SVNPath /absolute/path/to/myrepos
+</Location>
+@end example
+
+Ceci rend le dépôt @file{myrepos} disponible à l'URL
+@url{http://hostname/repos}, sans aucune restriction d'accès :
+
+@itemize @bullet
+@item
+Chaqu'un peut utiliser son client svn pour sortir une copie de travail, ou
+de toute URL qui correspond à un sous-répertoire du dépôt.
+@item
+En pointant un navigateur web ordinaire à l'URL, toute personne peut
+naviger intérectivement dans la dernière révision.
+@item
+Tout le monte peut remonter des modifications au dépôt.
+@end itemize
+
+Si vous voulez restreindre en lecture ou écriture l'accès à l'ensemble du
+dépôt, vous pouvez utiliser les facilités de contrôle d'accès d'Apache.
+
+Premièrement, créé un fichier vide qui contiendra les noms d'utilisateur
+et leur mot de passe. Renseigné les noms et les mots de passe cryptés dans
+le fichier comme ci-dessous:
+
+@example
+joe:Msr3lKOsYMkpc
+frank:Ety6rZX6P.Cqo
+mary:kV4/mQbu0iq82
+@end example
+
+Vous pouvez générer les mots de passe cryptés en utilisant une commande
+@command{crypt(3)} standard. Voici un petit programme perl qui le fait
+également:
+
+@example
+#!/usr/bin/perl
+srand (time());
+my $randletter = "(int (rand (26)) + (int (rand (1) + .5) % 2 ? 65 : 97))";
+my $salt = sprintf ("%c%c", eval $randletter, eval $randletter);
+my $plaintext = shift;
+my $crypttext = crypt ($plaintext, $salt);
+@end example
+
+Ndt : Le programme @command{htpasswd} d'Apache doit aussi faire
+l'affaire.
+
+Puis ajoutez ces quelques lignes dans votre block <Location> qui pointent
+sur le fichier des utilisateurs:
+
+@example
+AuthType Basic
+AuthName "Subversion repository"
+AuthUserFile /path/to/users/file
+@end example
+
+Si vous voulez restreindre @emph{tout} accès au dépôt, ajouter une ligne
+supplémentaire:
+
+@example
+Require valid-user
+@end example
+
+Cette ligne fait qu'Apache exigent un utilisateur authentifié pour toutes
+les requêtes http à votre dépôt.
+
+Pour restreindre les accès en écriture uniquement, vous devez exiger un
+utilisateur authentifié pour toutes les méthodes de requête sauf celles
+qui sont de type lecture seule:
+
+@example
+<LimitExcept GET PROPFIND OPTIONS REPORT>
+ Require valid-user
+</LimitExcept>
+@end example
+
+Ou, si vous voulez quelque chose de plus astucieux, vous pouvez créer deux
+groupes d'utilisateurs séparés, un pour les utilisateurs en lecture, un
+autre pour les utilisateurs en écriture:
+
+@example
+AuthGroupFile /my/svn/group/file
+
+<LimitExcept GET PROPFIND OPTIONS REPORT>
+ Require group svn_committers
+</LimitExcept>
+
+<Limit GET PROPFIND OPTIONS REPORT>
+ Require group svn_committers
+ Require group svn_readers
+</Limit>
+@end example
+
+Ce ne sont que de simples exemples. Pour un tutorial complet sur les
+contrôle d'accès d'Apache, regarder
+@url{http://httpd.apache.org/docs-2.0/misc/tutorials.html}.
+
+Autre remarque: pour que 'svn cp' marche (ce qui est actuellement
+implémenté comme une requête DAV COPY), mod_dav doit être capable de
+déterminer le hostname du serveur. Un moyen standard est d'utiliser la
+directive ServerName d'Apache pour fixer le hostname du serveur.
+
+Ndt: si UseCanonicalName d'apache est sur off il n'est pas forcément
+nécessaire de renseigner ServerName. Je vous conseile d'essayer en
+premier "UseCanonicalName Off" qui pose moins de problème lors des
+redirections par Apache.
+
+Editez votre @file{httpd.conf} pour inclure:
+
+@example
+ServerName svn.myserver.org
+@end example
+
+Si vous utilisez le "virtual hosting" d'apache avec la directive
+NameVirtualHost, vous pourrez avoir besoin d'utiliser la directive
+ServerAlias pour spécifier des noms additionnels par lesquels votre
+serveur est connu.
+
+Si vous n'est pas familier avec une directive d'Apache, ou pas très sûr
+de ce qu'elle fait, n'hésitez pas à consulter la documentation:
+@url{http://httpd.apache.org/docs-2.0/mod/directives.html}.
+
+Vous pouvez tester votre dépôt exporté en lançant httpd:
+
+@example
+$ /usr/local/apache2/bin/apachectl stop
+$ /usr/local/apache2/bin/apachectl start
+@end example
+
+Contrôler /usr/local/apache2/logs/error_log pour être sûre que sont
+démarrage est OK. Essayez une sortie via le réseau de votre dépôt:
+
+@example
+$ svn co http://localhost/repos -d wc
+@end example
+
+La raison la plus commune pour que celà ne marche pas est un problème de
+permission de lecture/écriture des fichiers db du dépôt. Assurez-vous que
+l'utilisateur 'nobody' (ou un autre UID utilisé par le processus httpd) a
+les permissions de lecture et écriture aux fichiers Berkeley DB! C'est le
+problème le plus courant.
+
+Vous pouvez voire toute les "plaintes" de mod_dav_svn dans le fichier
+d'erreur d'Apache, @file{/usr/local/apache2/logs/error_log} ou ailleur
+en fonction de votre installation d'Apache. Pour plus d'information sur le
+traçage des problèmes, regardez "Debugging the server" dans le fichier
+@file{HACKING}.
+
+
+@c ------------------------------------------------------------------
+@node Migrer un dépôt
+@section Migrer un dépôt
+
+Parfois des situations spéciales arrivent où vous devez déplacer tout
+votre donnée du système de fichier d'un dépôt vers un autre. Le schéma du
+système de fichier de la base de données a changé dans une nouvelle
+version de Subversion, ou peut-être vous voulez utiliser un moteur de base
+de donnée différent.
+
+Quoiqu'il en soit, vos données doivent être migrées vers un nouveau
+dépôt. Pour le faire, vous avez les commandes @command{svnadmin dump} et
+@command{svnadmin load}.
+
+@command{svnadmin dump} écrit un flux de vos données de votre dépôt vers
+la sortie standard (stdout):
+
+@example
+$ svnadmin dump myrepos > dumpfile
+* Dumped revision 0.
+* Dumped revision 1.
+* Dumped revision 2.
+[...]
+@end example
+
+Ce flux décrit toutes les révisions dans votre dépôt comme un liste de de
+modifications à des noeuds. C'est principalement du texte lisible par un
+humain; mais lorsqu'un contenu de fichier change, le contenu entier est
+envoyé dans le flux. Si vous avez des fichiers binaires ou des propriétés
+binaires dans votre dépôt, ces parties du flux pourront être moins lisible
+pour un humain. Plus loin, le flux complet sera appelé un dump.
+
+Après avoir extrait vos données, vous pouvez déplacer le fichier vers un
+système différent (ou quelque part ou l'environnement utilise une version
+différente de @command{svnadmin} et/ou @file{libsvn_fs.so}), et créer un
+``nouveau'' style de dépôt qui a un nouveau schéma ou moteur de base de
+données.
+
+@example
+$ svnadmin create newrepos
+@end example
+
+La commande @command{svnadmin load} est d'entreprendre de lire le dump
+depuis l'entrée standard (stdin) et de rejouer chaques remontées:
+
+@example
+$ svnadmin load newrepos < dumpfile
+<<< Started new txn, based on original revision 1
+ * adding path : A ... done.
+ * adding path : A/B ... done.
+[...]
+------- Committed new rev 1 (loaded from original rev 1) >>>
+
+<<< Started new txn, based on original revision 2
+ * editing path : A/mu ... done.
+ * editing path : A/D/G/rho ... done.
+
+------- Committed new rev 2 (loaded from original rev 2) >>>
+@end example
+
+Voilà, vos révisions ont été remontées dans le nouveau dépôt.
+
+@subsection Stupide dump/load astuces
+
+Les personne que aime "copiner" avec Unix peuvent essayer des choses comme
+celles ci:
+@example
+$ svnadmin create newrepos
+$ svnadmin dump myrepos | svnadmin load newrepos
+@end example
+
+Il est aussi possible de créer une série de petits fichiers dump et de les
+charger en série. Mais celà demande un peu de boulot.
+
+@example
+$ svnadmin dump myrepos 0 2000 > dumpfile1
+$ svnadmin dump myrepos 2000 4000 > dumpfile2
+@end example
+
+Donc maintenant vous avez deux fichiers de dump. Le premier contient les
+révision 0 à 2000, et le second contient les révisions 2000 à 4000.
+Pourquoi le recouvrement ?
+
+Voici le pourquoi. La première révision extraite par @command{svnadmin
+dump} est toujours comparée à la révision 0 qui est juste le répertoire
+racine @file{/} vide. Ceci signifie que la première révision de tout dump
+resemble toujours à une gigantesque liste de noeuds ``ajoutés''. Ce choix
+a été fait pour que tout fichier comme @file{dumpfile2} puisse être
+directement chargé dans un dépôt vide.
+
+Mais il y a un inconvénient à cet avantage. Lorsque nous voulons charger
+plusieurs fichiers de dump à la suite, Nous devons être sûr que chaques
+fichiers se recouvrent par au moins une révision. Avant le chargement, la
+première révision d'un fichier comme @file{dumpfile2} doit être
+@emph{supprimé}, ainsi le fichier commence par une description de la
+révision 2001 comme une différence d'arborescence par rapport à la
+révision 2000:
+
+@itemize @bullet
+@item
+Ouvrire le @file{dumpfile2} dans un éditeur
+@item
+ne @emph{pas} supprimer la ligne d'entête
+@code{SVN-fs-dump-format-version} au début du fichier.
+@item
+@emph{supprimer} la première révision, qui commence avec un enregistrement
+@code{Revision-number:}, et qui va jusqu'au prochain bloque
+@code{Revision-number:}.
+@end itemize
+
+Une fois que vos fichiers de dump ont été proprement "ajustés", vous
+pouvez les charger avec la séquence:
+
+@example
+$ svnadmin load newrepos < dumpfile1
+$ svnadmin load newrepos < dumpfile2
+@end example
+
Property changes on: ./doc/handbook/french/repos_admin.texi
___________________________________________________________________
Name: svn:eol-style
+ native
Index: ./dist.sh
===================================================================
--- ./dist.sh
+++ ./dist.sh Tue Jul 23 05:27:55 2002
@@ -98,9 +98,14 @@
rm -f doc/programmer/design/svn-design.info-*
rm -f doc/programmer/design/svn-design.html
rm -f doc/programmer/design/svn-design.txt
-rm -f doc/user/manual/svn-handbook.info
+rm -f doc/handbook/svn-handbook.info
+rm -f doc/handbook/svn-handbook.info-*
rm -f doc/handbook/svn-handbook.html
rm -f doc/handbook/svn-handbook.txt
+rm -f doc/handbook/french/svn-handbook-french.info
+rm -f doc/handbook/french/svn-handbook-french.info-*
+rm -f doc/handbook/french/svn-handbook-french.html
+rm -f doc/handbook/french/svn-handbook-french.txt
### Build new docs.
echo "Building new docs in docs/ ..."
@@ -170,9 +175,14 @@
doc/programmer/design/svn-design.info-* \
doc/programmer/design/svn-design.html \
doc/programmer/design/svn-design.txt \
- doc/handbook/svn-handbook.info \
- doc/handbook/svn-handbook.html \
- doc/handbook/svn-handbook.txt
+ doc/handbook/svn-handbook.info \
+ doc/handbook/svn-handbook.info-* \
+ doc/handbook/svn-handbook.html \
+ doc/handbook/svn-handbook.txt \
+ doc/handbook/french/svn-handbook-french.info \
+ doc/handbook/french/svn-handbook-french.info-* \
+ doc/handbook/french/svn-handbook-french.html \
+ doc/handbook/french/svn-handbook-french.txt
do
cp ${name} ${DIST_SANDBOX}/${DISTNAME}/${name}
done
Index: ./packages/rpm/subversion.spec
===================================================================
--- ./packages/rpm/subversion.spec
+++ ./packages/rpm/subversion.spec Tue Jul 23 05:37:44 2002
@@ -178,6 +178,10 @@
/sbin/install-info /usr/share/info/svn-handbook.info.gz \
/usr/share/info/dir \
--entry='* Subversion: (svn-handbook). Subversion Versioning System Manual'
+
+ /sbin/install-info /usr/share/info/svn-handbook-french.info.gz \
+ /usr/share/info/dir \
+ --entry='* Subversion-french: (svn-handbook-french). Guide du gestionnaire de version Subversion'
fi
fi
@@ -192,6 +196,10 @@
/sbin/install-info --delete /usr/share/info/svn-handbook.info.gz \
/usr/share/info/dir \
--entry='* Subversion: (svn-handbook). Subversion Versioning System Manual'
+
+ /sbin/install-info --delete /usr/share/info/svn-handbook-french.info.gz \
+ /usr/share/info/dir \
+ --entry='* Subversion-french: (svn-handbook-french). Guide du gestionnaire de version Subverion'
fi
fi
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 25 10:22:20 2002