diff --git a/Manuals/Docbook/repository-parts.docbook b/Manuals/Docbook/repository-parts.docbook
new file mode 100644
index 0000000..b0a2794
--- /dev/null
+++ b/Manuals/Docbook/repository-parts.docbook
@@ -0,0 +1,12 @@
+<?xml version="1.0"?>
+<part>
+ <title>Repository</title>
+ &intro;
+ &directories;
+</part>
+
+<part>
+ <title>Licenses</title>
+ &licenses-gpl;
+ &licenses-gfdl;
+</part>
diff --git a/Manuals/Docbook/repository-parts/Directories.docbook b/Manuals/Docbook/repository-parts/Directories.docbook
new file mode 100644
index 0000000..0b20104
--- /dev/null
+++ b/Manuals/Docbook/repository-parts/Directories.docbook
@@ -0,0 +1,18 @@
+<?xml version="1.0"?>
+<chapter id="directories" xreflabel="Directories">
+
+ <title>Directories</title>
+
+ <para>The CentOS Artwork Repository uses directories to organize
+ files and describe conceptual idea about corporate identity. Such
+ conceptual ideas are explained in each directory related
+ documentation entry.</para>
+
+ <para>In this chapter you'll learn what each directory inside The
+ CentOS Artwork Repository is for and so, how you can make use of
+ them. For that purpose, the following list of directories is
+ available for you to explore:</para>
+
+ &directories-trunk;
+
+</chapter>
diff --git a/Manuals/Docbook/repository-parts/Introduction.docbook b/Manuals/Docbook/repository-parts/Introduction.docbook
index fad872e..47daa93 100644
--- a/Manuals/Docbook/repository-parts/Introduction.docbook
+++ b/Manuals/Docbook/repository-parts/Introduction.docbook
@@ -7,16 +7,16 @@
Manual</emphasis>.</para>
<para>The CentOS Artwork Repository Manual describes how The
- CentOS Project Corporate Visual Identity is organized and produced
+ CentOS Project corporate visual identity is organized and produced
inside the CentOS Artwork Repository (<ulink
url="https://projects.centos.org/svn/artwork/" />). If you are
looking for a comprehensive, task-oriented guide for understanding
- how The CentOS Project Corporate Visual Identity is produced, this
+ how The CentOS Project corporate visual identity is produced, this
is the manual for you.</para>
<para>This guide assumes you have a basic understanding of The
CentOS Distribution. If you need help with CentOS, refer to the
- help page on the CentOS Wiki (<ulink
+ help page on The CentOS Wiki (<ulink
url="http://wiki.centos.org/Help" />) for a list of different
places you can find help.</para>
diff --git a/Manuals/Docbook/repository-parts/Introduction/copying.docbook b/Manuals/Docbook/repository-parts/Introduction/copying.docbook
new file mode 100644
index 0000000..9b3ff50
--- /dev/null
+++ b/Manuals/Docbook/repository-parts/Introduction/copying.docbook
@@ -0,0 +1,92 @@
+<?xml version="1.0"?>
+<sect1 id="intro-copying" xreflabel="Copying conditions">
+
+ <title>Copying conditions</title>
+
+ <para>Copyright © 2009, 2010, 2011 The CentOS Project</para>
+ <para>Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.</para>
+
+ <sect2 id="intro-copying-preamble" xreflabel="Preamble">
+
+ <title>Preamble</title>
+
+ <para>The CentOS Artwork Repository organizes files in a very
+ specific way to implement The CentOS Project corporate visual
+ identity. This very specific organization of files must be
+ considered part of <command>centos-art.sh</command> script, a bash
+ script that automate most of the frequent tasks inside the
+ repository.</para>
+
+ <para>The <command>centos-art.sh</command> script and the
+ organization of files it needs to work are not in the public
+ domain; they are copyrighted and there are restrictions on their
+ distribution, but these restrictions are designed to permit
+ everything that a good cooperating citizen would want to do. What
+ is not allowed is to try to prevent others from further sharing
+ any version of this program that they might get from you.</para>
+
+ <para>Specifically, we want to make sure that you have the right
+ to give away copies of <command>centos-art.sh</command> script and
+ the organization of files it needs to work, that you receive
+ source code or else can get it if you want it, that you can change
+ this program or use pieces of it in new free programs, and that
+ you know you can do these things.</para>
+
+ <para>To make sure that everyone has such rights, we have to
+ forbid you to deprive anyone else of these rights. For example,
+ if you distribute copies of the <command>centos-art.sh</command>
+ script, you must give the recipients all the rights that you have.
+ You must make sure that they, too, receive or can get the source
+ code. And you must tell them their rights.</para>
+
+ <para>Also, for our own protection, we must make certain that
+ everyone finds out that there is no warranty for the
+ <command>centos-art.sh</command> script. If this program is
+ modified by someone else and passed on, we want their recipients
+ to know that what they have is not what we distributed, so that
+ any problems introduced by others will not reflect on our
+ reputation.</para>
+
+ <para>The <command>centos-art.sh</command> script is released as a
+ GPL work. Individual packages used by
+ <command>centos-art.sh</command> script include their own licenses
+ and the <command>centos-art.sh</command> script license applies to
+ all packages that it does not clash with. If there is a clash
+ between the <command>centos-art.sh</command> script license and
+ individual package licenses, the individual package license
+ applies instead.</para>
+
+ <para>The precise conditions of the license for the
+ <command>centos-art.sh</command> script are found in the <xref
+ linkend="licenses-gpl" />. This manual specifically is
+ covered by the <xref linkend="licenses-gfdl" />.</para>
+ </sect2>
+
+ <sect2 id="intro-copying-brand" xreflabel="The CentOS Brand">
+
+ <title>The CentOS Brand</title>
+
+ <para>The CentOS Brand () is the main visual manifestaion of The
+ CentOS Project. The CentOS Project uses The CentOS Brand to
+ connect all its visual manifestions (e.g., GNU/Linux
+ Distributions, Websites, Stationery, etc.) and, this way, it
+ provides recognition among other similar projects available on the
+ Internet.</para>
+
+ <para>Both The CentOS Brand and all the visual manifestations that
+ derivate from it are available for you to study and propose
+ improvement around a good citizen's will at The CentOS Community
+ environment, but you are not allowed to redistribute them
+ elsewhere, without the given permission of The CentOS
+ Project.</para>
+
+ <para>If you need to redistribute either The CentOS Brand or any
+ visual manifestation derived from it, write your intentions to the
+ The CentOS Developers mailing list
+ (centos-devel@centos.org).</para>
+
+ </sect2>
+
+</sect1>
+
diff --git a/Manuals/Docbook/repository-parts/Introduction/history.docbook b/Manuals/Docbook/repository-parts/Introduction/history.docbook
index 47e55be..cd6ff4d 100644
--- a/Manuals/Docbook/repository-parts/Introduction/history.docbook
+++ b/Manuals/Docbook/repository-parts/Introduction/history.docbook
@@ -3,11 +3,11 @@
<title>History</title>
- <para>The CentOS Artwork Repository started around 2008, at CentOS
- Developers mailing list (centos-devel@centos.org) during a
- discussion about how to automate the slide images of Anaconda. In
- such discussion, Ralph Angenendt rose up his hand to ask: Do you
- have something to show?</para>
+ <para>The CentOS Artwork Repository started around 2008 during a
+ discussion about how to automate the slide images of Anaconda, at
+ CentOS Developers mailing list (centos-devel@centos.org). In such
+ discussion, Ralph Angenendt rose up his hand to ask —Do you have
+ something to show?—.</para>
<para>To answer the question, I suggested a bash script which
combined SVG and SED files in order to produce PNG images in
@@ -62,34 +62,37 @@
structure, based on the mission and the release schema of The
CentOS Project.</para>
- <para>The directory structures started to be documented inside the
- repository using text files without markup. Later, documentation
- in flat text files was moved to LaTeX format and this way
- <quote>The CentOS Artwork Repository Manual</quote> started to
- take form.</para>
+ <para>The repository directory structures began to be documented
+ inside by mean of flat text files. Later, documentation in flat
+ text files was moved onto LaTeX format and this way <quote>The
+ CentOS Artwork Repository Manual</quote> is initiated.</para>
<para>Around 2010, the rendition script changed its name from
<command>render.sh</command> to <command>centos-art.sh</command>
and became a collection of functionalities where rendition was
just one among others (e.g., documenting and localizing).</para>
- <para>The <command>centos-art.sh</command> was created to organize
- automation of most frequent tasks inside the repository. There
- was no need to have links all around the repository if a
- command-line interface could be created (through symbolic links,
- in the <filename class="directory">~/bin</filename> directory) and
- be called anywhere inside the repository as it would be a regular
- command.</para>
-
- <para>Inside <command>centos-art.sh</command>, functionalities
- started to get identified and separated one another. For example,
- when images were rendered, there was no need to load
- functionalities related to documentation manual. This layout moved
- us onto common functionalities and specific functionalities inside
- <command>centos-art.sh</command> script. Common functionalities
- are loaded when <command>centos-art.sh</command> script is
- initiated and are available to specific functionalities.</para>
+ <para>The <command>centos-art.sh</command> was initialy conceived
+ to organize automation of most frequent tasks inside the
+ repository based in the conceptual idea of Unix toolbox:
+ <emphasis>create small and specialized tools that do one thing
+ well</emphasis>. This way, functionalities inside
+ <command>centos-art.sh</command> were identified and separated one
+ another. For example, when images were rendered, there was no need
+ to load functionalities related to documentation manual. This
+ layout moved us onto common functionalities and specific
+ functionalities inside <command>centos-art.sh</command> script.
+ Common functionalities are loaded when
+ <command>centos-art.sh</command> script is initiated and are
+ available to specific functionalities.</para>
+ <para>There was no need to have links all around the
+ repository if a command-line interface could be created (through
+ symbolic links, in the <filename
+ class="directory">~/bin</filename> directory) and be called
+ anywhere inside the repository as it would be a regular
+ command.</para>
+
<para>The <command>centos-art.sh</command> script was redesigned
to handle command-line options trough <command>getopt</command>
option parser.</para>
@@ -124,9 +127,9 @@
translators and programmers to produce localized content. The SED
files are no longer used to handle translations.</para>
- <para>Consolidate the <code>render</code>, <code>help</code> and
- <code>locale</code> functionalities as the most frequent tasks
- performed inside the repository. Additionally, the
+ <para>The <code>render</code>, <code>help</code> and
+ <code>locale</code> functionalities were consolidated as the most
+ frequent tasks performed inside the repository. Additionally, the
<code>prepare</code> and <code>tuneup</code> functionalities are
maintained as useful tasks.</para>
diff --git a/Manuals/Docbook/repository-parts/Introduction/usage.docbook b/Manuals/Docbook/repository-parts/Introduction/usage.docbook
new file mode 100644
index 0000000..c281a12
--- /dev/null
+++ b/Manuals/Docbook/repository-parts/Introduction/usage.docbook
@@ -0,0 +1,370 @@
+<?xml version="1.0"?>
+<sect1 id="intro-usage" xreflabel="Usage convenctions">
+
+ <title>Usage convenctions</title>
+
+ <para>The CentOS Artwork Repository is supported by Subversion
+ (http://subversion.tigris.org/), a version control system which
+ allows you to keep old versions of files and directories (usually
+ source code), keep a log of who, when, and why changes occurred,
+ etc., like CVS, RCS or SCCS.</para>
+
+ <para>When using Subversion there is one "source repository" and
+ many "working copies" of that source repository. The working
+ copies are independent one another, can be distributed all around
+ the world and provide a local place for designers, documentors,
+ translators and programmers to perform their work in a
+ descentralized way. The source repository, on the other hand,
+ provides a central place for all independent working copies to
+ interchange data and provides the information required to permit
+ extracting previous versions of files at any time.</para>
+
+ <sect2 id="repo-usage-policy" xreflabel="Policy">
+
+ <title>Policy</title>
+
+ <para>The CentOS Artwork Repository is a collaborative tool
+ that anyone can have access to. However, changing that tool in
+ any form is something that should be requested in the CentOS
+ Developers mailing list (centos-devel@centos.org). Generally,
+ people download working copies from CentOS Artwork Repository,
+ study the repository organization, make some changes in their
+ working copies, make some tests to verify such changes do work
+ the way expected and finally request access to commit them up
+ to the CentOS Artwork Repository (i.e., the source repository)
+ for others to benefit from them.</para>
+
+ <para>Once you've received access to commit your changes,
+ there is no need for you to request permission again to commit
+ other changes from your working copy to CentOS Artwork
+ Repository as long as you behave as a <emphasis>good
+ cooperating citizen</emphasis>. Otherwise, your rights to
+ commit changes might be temporarly revoked or permanently
+ banished.</para>
+
+ <para>As a good cooperating citizen one understand of a person
+ who respects the work already done by others and share ideas
+ with authors before changing relevant parts of their work,
+ specially in situations when the access required to realize
+ the changes has been granted already. Of course, there is a
+ time when conversation has taken place, the paths has been
+ traced and changing the work is so obvious that there is no
+ need for you to talk about it; that's because you already did,
+ you already built the trust to keep going. Anyway, the mailing
+ list mentioned above is available for sharing ideas in a way
+ that good relationship between community citizens could be
+ constantly balanced.</para>
+
+ <para>The relationship between community citizens is monitored
+ by repository administrators. Repository administrators are
+ responsible of granting that everything goes the way it needs
+ to go in order for the CentOS Artwork Repository to accomplish
+ its mission which is: to provide a colaborative tool for The
+ CentOS Community where The CentOS Project corporate visual
+ identity is built and maintained by The CentOS Community
+ itself.</para>
+
+ <para>It is also important to remember that all the program
+ and documentation source files inside CentOS Artwork
+ Repository must comply the terms of <xref
+ linkend="licenses-gpl" /> and <xref linkend="licenses-gfdl" />
+ respectively in order for them to remain inside the
+ repository.</para>
+
+ </sect2>
+
+ <sect2 id="intro-usage-worklines" xreflabel="Worklines">
+
+ <title>Work lines</title>
+
+ <para>Content production inside the repository is organized by
+ <emphasis>work lines</emphasis>. There are three major work
+ lines of production inside The CentOS Artwork Repository,
+ which are: <emphasis>Graphic design</emphasis>,
+ <emphasis>Documentation</emphasis> and
+ <emphasis>Localization</emphasis>. The specific way of
+ producing content inside each specific work line is
+ standardized by mean of <command>centos-art.sh</command>
+ script (which in turn, can be considered a work line by itself
+ [e.g., the <emphasis>Automation</emphasis> work line]). The
+ <command>centos-art.sh</command> script provides one specific
+ functionality for automating each major work line of content
+ production (e.g., <code>render</code> for producing images,
+ <code>help</code> for manage documentation, and
+ <code>locale</code> for localizing contents).</para>
+
+ <para>The graphic design work line exists to cover brand
+ design, typography design and themes design mainly.
+ Additionally, some auxiliar areas like icon design,
+ illustration design, brushes design, patterns designs and
+ palettes of colors are also included here for completeness.
+ The graphic design work line is organized in the <filename
+ class="directory">trunk/Identity</filename> directory.</para>
+
+ <para>The documentation work line exists to describe what each
+ directory inside the CentOS Artwork Repository is for, the
+ conceptual ideas behind them and, if possible, how automation
+ scripts make use of them. The documentation work line is
+ organized in the <filename
+ class="directory">trunk/Manuals</filename> directory.</para>
+
+ <para>The localization work line exists to provide the
+ translation messages required to produce content in different
+ languages. Translation messages inside the repository are
+ stored as portable objects (e.g., .po, .pot) and machine
+ objects (.mo). The localization work line is organized in the
+ <filename class="directory">trunk/Locales</filename>
+ directory.</para>
+
+ <para>The automation work line exists to standardize content
+ production inside the working copies of CentOS Artwork
+ Repository. Here is developed the
+ <command>centos-art.sh</command> script, a bash script
+ specially designed to automate most frequent tasks (e.g.,
+ rendition, documentation and localization) inside the
+ repository. There is no need to type several tasks, time
+ after time, if they can be programmed into just one executable
+ script. The automation work line is organized in the
+ <filename class="directory">trunk/Scripts</filename>
+ directory.</para>
+
+ </sect2>
+
+ <sect2 id="intro-usage-conbdirs" xreflabel="Relation between directories">
+
+ <title>Relation between directories</title>
+
+ <para>In order for automation scripts to produce content inside a
+ working copy of CentOS Artwork Repository, it is required that all
+ work lines be related somehow. The relation is used by automation
+ scripts to know where to retrive the information they need to work
+ with (e.g., design model, translation messages, output locations,
+ etc.). This kind of relation is built using two path
+ constructions named <emphasis>master paths</emphasis> and
+ <emphasis>auxiliar paths</emphasis>.</para>
+
+ <para>The master path points only to directories that contain
+ source files (e.g., SVG files) required to produce output base
+ content (e.g., PNG files) through automation scripts. Each master
+ path inside the repository may have several auxiliar paths
+ associated, but auxiliar paths can only have one master path
+ associated.</para>
+
+ <para>Master paths used for producing images through SVG rendition
+ are organized under <filename
+ class="directory">trunk/Identity/Models</filename> directory
+ structure and the auxiliar paths under <filename
+ class="directory">trunk/Identity/Images</filename>, <filename
+ class="directory">trunk/Locales</filename> and <filename
+ class="directory">trunk/Manuals</filename> directory
+ structures.</para>
+
+ <para>Auxiliar paths can point either to directories or files.
+ When an auxiliar path points to a directory, that directory
+ contains information that modifies somehow the content produced
+ from master paths (e.g., translation messages) or provides the
+ output information required to know where the content produced
+ from the master path should be stored. When an auxiliar path
+ points to a file, that file has no other purpose but to document
+ the master path it refers to.</para>
+
+ <para>Auxiliar paths should never be modified under any reason but
+ to satisfy the relationship with the master path. Liberal change
+ of auxiliar paths may suppress the conceptual idea they were
+ initially created for; and certainly, automation scripts may stop
+ working as expected.</para>
+
+ <para>The relationship between auxiliar paths and master paths is
+ built by combining the master path and the second level directory
+ structures of the repository. The master path is considered the
+ path identifier and the repository second level directory
+ structure is considered the common part of the path where the path
+ identifier is appended to. So, if we have the master path
+ <filename
+ class="directory">trunk/Identity/Models/Brands</filename>, we'll
+ end up having, at least, the <filename
+ class="directory">trunk/Identity/Images/Brands</filename> auxiliar
+ path for storing output files and, optionally, one path under
+ <filename class="directory">trunk/Manuals</filename> for storing
+ documentation and one path under <filename
+ class="directory">trunk/Locales</filename> for storing
+ localizations.</para>
+
+ </sect2>
+
+ <sect2 id="intro-usage-syncro" xreflabel="Syncronizing paths">
+
+ <title>Syncronizing paths</title>
+
+ <para>Once both master paths and their auxiliar paths have been
+ set, they shouldn't be changed. Assuming one master path must be
+ changed it is required that all related auxiliar paths be changed,
+ too. This is required in order for master paths to retain their
+ relation with auxiliar paths. This process of keeping relation
+ between master paths and auxiliar paths is known as <emphasis>path
+ syncronization</emphasis>. </para>
+
+ <para>Path syncronization is required for automation scripts to
+ know where to store final output, where to retrive translation
+ messages, documentation, and any information that might be
+ desired. If the relation between master paths and auxiliar paths
+ is lost, there is no way for <command>centos-art.sh</command>
+ script to know where to retrive the information it needs to work
+ with. Path syncronization is the way we use to organize and
+ extend the information stored in the repository.</para>
+
+ <para>Path syncronization may imply both movement of files and
+ replacement of content inside files. Movement of files is related
+ to actions like renaming files and directories inside the
+ repository. Replacement of content inside files is related to
+ actions like replacing information (e.g., paths information)
+ inside files in order to keep file contents and file locations
+ consistent one another.</para>
+
+ <para>The order followed to syncronize path information is very
+ important because the versioned nature of the repository files we
+ are working with. When a renaming action must be performed, we
+ avoid making replacements inside files first and file movements
+ later. This would require two commit actions: one for the files'
+ internal changes and another for the file movement itself.
+ Otherwise, we prefer to perform file movements first and file
+ internal replacements later. This way it is possible to commit
+ both changes as if they were just one.</para>
+
+ <warning><para>There is no support for URLs actions inside
+ <command>centos-art.sh</command> script. The
+ <command>centos-art.sh</command> script is designed to work with
+ local files inside the working copy only. If you need to perform
+ URL actions directly, use Subversion commands
+ instead.</para></warning>
+
+ <para>At this moment there is no full implementation of path
+ syncronization process inside <command>centos-art.sh</command>
+ script except by <quote>texinfo</quote> backend of
+ <code>help</code> functionality which provides a restricted
+ implementation of path syncronization to this specific area of
+ documentation through the <option>--copy</option>,
+ <option>--delete</option> and <option>--rename</option> options.
+ The plan for a full implementation of path syncronization would be
+ to create individual restricted implementations like this one for
+ other areas that demand it and then, create a higher implmentation
+ that combines all restricted implementations as needed. This way,
+ if we try to rename a repository directory the higer action will
+ define which are all the restricted actions that should be
+ performed in order for make a full path syncronization. For
+ example, if the directory we are renaming is part of graphic
+ design work line, it is required to syncronize related paths in
+ documentation and localization work lines. Likewise, if the
+ directory we are renaming is in documentation work line, it is
+ required to syncronize related paths in graphic design and
+ localization work lines. In all these cases, the direction used
+ for syncronizing paths must be from master path to auxiliar path
+ and never the opposite (i.e., rename the master path first and
+ auxiliar paths later).</para>
+
+ <para>A practical example, through which you can notice the
+ usefulness of path syncronization process, is what happen when
+ documentation entries are renamed (see section ...).</para>
+
+ </sect2>
+
+ <sect2 id="intro-usage-extending" xreflabel="Extending repository
+ organization">
+
+ <title>Extending repository organization</title>
+
+ <para>Occasionly, you may find that new components of The
+ CentOS Project corporate visual identity need to be added to
+ the repository in order to work them out. If that is the case,
+ the first question we need to ask ourselves, before start to
+ create directories blindly all over, is: <emphasis>What is the
+ right place to store it?</emphasis></para>
+
+ <para>The best place to find answers is in The CentOS
+ Community (see page http://wiki.centos.org/Help), but going
+ there with hands empty is not good idea. It may give the
+ impression you don't really care about. Instead, consider the
+ following suggestions to find your own comprehension in order
+ to make your own propositions based on it.</para>
+
+ <para>When extending respository structure it is very useful
+ to bear in mind The CentOS Project corporate visual identity
+ structure, The CentOS Mission and The CentOS Release Schema.
+ The rest is a matter of choosing appropriate names. It is also
+ worth to know that each directory in the repository responds
+ to a conceptual idea that justifies its existence.</para>
+
+ <para>To build a directory structure inside the repository,
+ you need to define the conceptual idea first and later create
+ the directory, remembering that there are locations inside the
+ repository that define conceptual ideas you probably would
+ prefer to reuse. For example, the <filename
+ class="directory">trunk/Identity/Images/Themes</filename>
+ directory stores theme artistic motifs, the <filename
+ class="directory">trunk/Identity/Models/Themes</filename>
+ directory stores theme design models, the <filename
+ class="directory">trunk/Manuals</filename> directory stores
+ documentation files, the <filename
+ class="directory">trunk/Locales</filename> stores translation
+ messages, and the <filename
+ class="directory">trunk/Scripts</filename> stores automation
+ scripts.</para>
+
+ <para>To better illustrate this desition process, you can
+ consider to examin the <filename
+ class="directory">trunk/Identity/Images/Themes/TreeFlower/3</filename>
+ directory structure as example. This directory can be read
+ as: the theme development line of version <quote>3</quote> of
+ <quote>TreeFlower</quote> artistic motif. Additional, we can
+ say that <quote>TreeFlower</quote> artistic motif is part of
+ themes, as themes are part of The CentOS Project corporate
+ visual identity.</para>
+
+ <para>The relationship between conceptual ideas can be
+ stablished by reading each repository documentation entry
+ individually, from <filename
+ class="directory">trunk</filename> directory to a deeper
+ directory in the path. For reading repository documentation
+ entries we use the <code>help</code> functionality of
+ <command>centos-art.sh</command> script.</para>
+
+ </sect2>
+
+ <sect2 id="intro-usage-filenames" xreflabel="File names convenction">
+
+ <title>File names convenction</title>
+
+ <para>Inside the CentOS Artwork Repository, generally, file
+ names are all written in lowercase (e.g.,
+ <filename>01-welcome.png</filename>,
+ <filename>splash.png</filename>,
+ <filename>anaconda_header.png</filename>, etc.) and directory
+ names are all written capitalized (e.g., <filename
+ role="directory">Identity</filename>, <filename
+ role="directory">Themes</filename>, <filename
+ role="directory">Motifs</filename>) and sometimes in cammel
+ case (e.g., <filename role="directory">TreeFlower</filename>,
+ etc.). </para>
+
+ <para>In the very specific case of repository documentation
+ entries, file names follow the directory naming convenction.
+ This is because they are documenting directories and that is
+ something we want to remark. So, to better describe what we
+ are documenting, documentation entries follow the name
+ convenction used by the item they document.</para>
+
+ </sect2>
+
+ <sect2 id="intro-usage-layout" xreflabel="Repository layout">
+
+ <title>Repository layout</title>
+
+ <para>The CentOS Artwork Repository is organized through a
+ convenctional <quote>trunk</quote>, <quote>branches</quote>
+ and <quote>tags</quote> layout. Explanation of each directory
+ inside the repository can be found in the <xref
+ linkend="directories" /> chapter.</para>
+
+ </sect2>
+
+</sect1>
diff --git a/Manuals/Docbook/repository-preamble.docbook b/Manuals/Docbook/repository-preamble.docbook
new file mode 100644
index 0000000..30ed14d
--- /dev/null
+++ b/Manuals/Docbook/repository-preamble.docbook
@@ -0,0 +1,42 @@
+<?xml version="1.0"?>
+<bookinfo>
+
+ <title>The CentOS Artwork Repository Manual</title>
+
+ <authorgroup>
+ <author>
+ <firstname>Alain</firstname>
+ <surname>Reguera Delgado</surname>
+ </author>
+ </authorgroup>
+
+ <!-- Copyright: The copyright page is verso and contains the
+ copyright notice, the publishing/printing history, the country
+ where printed, ISBN and/or CIP information. The page is usually
+ typeset in a smaller font than the normal text. -->
+ <copyright>
+ <year>2009</year>
+ <year>2010</year>
+ <year>2011</year>
+ <holder>The CentOS Artwork SIG</holder>
+ </copyright>
+
+ <legalnotice>
+ <para>Permission is granted to copy, distribute and/or modify
+ this document under the terms of the GNU Free Documentation
+ License, Version 1.2 or any later version published by the
+ Free Software Foundation; with no Invariant Sections, no
+ Front-Cover Texts, and no Back-Cover Texts. A copy of the
+ license is included in the section entitled <xref
+ linkend="licenses-gfdl" />.</para>
+ </legalnotice>
+
+ <date>May, 2011</date>
+
+ <abstract>
+ <para>This manuals documents relevant information regarding
+ the deployment, organization, and administration of CentOS
+ Artwork Repository.</para>
+ </abstract>
+
+</bookinfo>