Le mer 17/07/2002 à 16:44, Ben Collins-Sussman a écrit :
>
> Hi all... in case you didn't notice my checkin last night, the first
> draft of the Subversion Handbook is done. Everyone, please feel free
> to proofread it, check for spelling & grammar errors, etc. I want
> this document to be the "main" documentation that ships in the
> Subversion tree, which is why all the old docs have suddenly
> disappeared. The Handbook is all we have to go on until,
> well... until a certain O'Reilly book is released. :-)
>
Sorry for my poor english.
I do a traslation in french of your "beautiful" handbook.
My translation correspond to the revision 2610 of Subversion.
I don't translate the License term witch is critical.
See the attachment for a diff against revision 2638.
One critical of the handbook :
* in repos_admin.texi (@node Networking a repository)
You recommend to add "ServerName svn.myserver.org" in httpd.conf file.
I think this is useless if "UseCanonicalName Off" is define in the
httpd.conf file.
UseCanonicalName :
# URLs and the SERVER_NAME and SERVER_PORT variables.
# When set "Off", Apache will use the Hostname and Port supplied
# by the client. When set "On", Apache will use the value of the
# ServerName directive.
I found "UseCanonicalName Off" better than "ServerName
svn.myserver.org".
For exemple, my repository in my computer is available with :
http://127.0.0.1/svn/repos/myrepos
http://localhost/svn/repos/myrepos
http://myhostname/svn/repos/myrepos
without any troubles. This is also better with complex rewriterule
redirection and work also fine with virtual named hosting.
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 Tue Jul 23 11:48:47 2002