diff --git a/Manuals/TCAR-UG/Docbook/Commons.ent b/Manuals/TCAR-UG/Docbook/Commons.ent
index 1c9682f..3908d9f 100644
--- a/Manuals/TCAR-UG/Docbook/Commons.ent
+++ b/Manuals/TCAR-UG/Docbook/Commons.ent
@@ -22,6 +22,7 @@
<!ENTITY TCC "&TC; Community">
<!ENTITY TCD "&TC; Distribution">
<!ENTITY TCA "&TC; Artwork">
+<!ENTITY TCM "<ulink url='http://mirrors.centos.org/'>&TC; Mirrors</ulink>">
<!ENTITY TCPCI "&TCP; &CI;">
<!ENTITY TCPCVI "&TCP; &CVI;">
@@ -36,7 +37,9 @@
<!ENTITY TCDRS "&TCD; Release Schema">
<!ENTITY TCAML "<ulink type='http' url='http://lists.centos.org/mailman/centos-artwork'>&TCA; Mailing List</ulink>">
<!ENTITY TCDML "<ulink type='http' url='http://lists.centos.org/mailman/centos-devel'>&TC; Developers Mailing List</ulink>">
+<!ENTITY TCML "<ulink type='http' url='http://lists.centos.org/mailman/centos-info'>&TC; Mailing List</ulink>">
<!ENTITY TCW "&TC; Web">
<!ENTITY TCS "&TC; Showroom">
<!ENTITY TCB "&TC; Brand">
<!ENTITY TCM "&TC; Mission">
+<!ENTITY TCDOCS "<ulink type='http' url='http://www.centos.org/docs/'>&TC; Documentation</ulink>">
diff --git a/Manuals/TCAR-UG/Docbook/Repository.docbook b/Manuals/TCAR-UG/Docbook/Repository.docbook
index 03f3458..bdef5f2 100644
--- a/Manuals/TCAR-UG/Docbook/Repository.docbook
+++ b/Manuals/TCAR-UG/Docbook/Repository.docbook
@@ -2,10 +2,10 @@
<title>Repository</title>
- &repo-history;
- &repo-copying;
- &repo-usage;
- &repo-worklines;
&repo-layout;
+ &repo-whatis;
+ &repo-ws;
+ &repo-worklines;
+ &repo-history;
</part>
diff --git a/Manuals/TCAR-UG/Docbook/Repository.ent b/Manuals/TCAR-UG/Docbook/Repository.ent
index 025a53c..f819360 100644
--- a/Manuals/TCAR-UG/Docbook/Repository.ent
+++ b/Manuals/TCAR-UG/Docbook/Repository.ent
@@ -1,28 +1,34 @@
-<!ENTITY repo SYSTEM "Repository.docbook">
+<!ENTITY repo SYSTEM "Repository.docbook">
-<!ENTITY repo-history SYSTEM "Repository/History.docbook">
-<!ENTITY repo-history-2009 SYSTEM "Repository/History/2009.docbook">
-<!ENTITY repo-history-2010 SYSTEM "Repository/History/2010.docbook">
-<!ENTITY repo-history-2011 SYSTEM "Repository/History/2011.docbook">
+<!ENTITY repo-history SYSTEM "Repository/History.docbook">
+<!ENTITY repo-history-2009 SYSTEM "Repository/History/2009.docbook">
+<!ENTITY repo-history-2010 SYSTEM "Repository/History/2010.docbook">
+<!ENTITY repo-history-2011 SYSTEM "Repository/History/2011.docbook">
-<!ENTITY repo-copying SYSTEM "Repository/Copying.docbook">
-<!ENTITY repo-copying-preamble SYSTEM "Repository/Copying/preamble.docbook">
+<!ENTITY repo-worklines SYSTEM "Repository/Worklines.docbook">
+<!ENTITY repo-worklines-identity SYSTEM "Repository/Worklines/identity.docbook">
+<!ENTITY repo-worklines-l10n SYSTEM "Repository/Worklines/l10n.docbook">
+<!ENTITY repo-worklines-manuals SYSTEM "Repository/Worklines/manuals.docbook">
+<!ENTITY repo-worklines-scripts SYSTEM "Repository/Worklines/scripts.docbook">
-<!ENTITY repo-docconvs SYSTEM "Repository/Docconvs.docbook">
+<!ENTITY repo-ws SYSTEM "Repository/Workstation.docbook">
+<!ENTITY repo-ws-overview SYSTEM "Repository/Workstation/overview.docbook">
+<!ENTITY repo-ws-install SYSTEM "Repository/Workstation/install.docbook">
+<!ENTITY repo-ws-config SYSTEM "Repository/Workstation/config.docbook">
-<!ENTITY repo-copying SYSTEM "Repository/Copying.docbook">
-<!ENTITY repo-worklines SYSTEM "Repository/Worklines.docbook">
-<!ENTITY repo-worklines-identity SYSTEM "Repository/Worklines/identity.docbook">
-<!ENTITY repo-worklines-l10n SYSTEM "Repository/Worklines/l10n.docbook">
-<!ENTITY repo-worklines-manuals SYSTEM "Repository/Worklines/manuals.docbook">
-<!ENTITY repo-worklines-scripts SYSTEM "Repository/Worklines/scripts.docbook">
+<!ENTITY repo-whatis SYSTEM "Repository/Whatis.docbook">
+<!ENTITY repo-whatis-authoring SYSTEM "Repository/Whatis/authoring.docbook">
+<!ENTITY repo-whatis-mission SYSTEM "Repository/Whatis/mission.docbook">
+<!ENTITY repo-whatis-publishing SYSTEM "Repository/Whatis/publishing.docbook">
+<!ENTITY repo-whatis-copying SYSTEM "Repository/Whatis/copying.docbook">
-<!ENTITY repo-usage SYSTEM "Repository/Usage.docbook">
+<!ENTITY repo-usage SYSTEM "Repository/Usage.docbook">
+<!ENTITY repo-usage-preparing SYSTEM "Repository/Usage/preparing.docbook">
+<!ENTITY repo-usage-register SYSTEM "Repository/Usage/register.docbook">
+<!ENTITY repo-usage-copying SYSTEM "Repository/Usage/copying.docbook">
-<!ENTITY repo-layout SYSTEM "Repository/Layout.docbook">
-<!ENTITY repo-layout-relbdirs SYSTEM "Repository/Layout/relbdirs.docbook">
-<!ENTITY repo-layout-syncpaths SYSTEM "Repository/Layout/syncpaths.docbook">
-<!ENTITY repo-layout-extending SYSTEM "Repository/Layout/extending.docbook">
-<!ENTITY repo-layout-filenames SYSTEM "Repository/Layout/filenames.docbook">
-
-<!ENTITY repo-feedback SYSTEM "Repository/Feedback.docbook">
+<!ENTITY repo-convs SYSTEM "Repository/Convenctions.docbook">
+<!ENTITY repo-convs-relbdirs SYSTEM "Repository/Convenctions/relbdirs.docbook">
+<!ENTITY repo-convs-syncpaths SYSTEM "Repository/Convenctions/syncpaths.docbook">
+<!ENTITY repo-convs-extending SYSTEM "Repository/Convenctions/extending.docbook">
+<!ENTITY repo-convs-filenames SYSTEM "Repository/Convenctions/filenames.docbook">
diff --git a/Manuals/TCAR-UG/Docbook/Repository/Convenctions.docbook b/Manuals/TCAR-UG/Docbook/Repository/Convenctions.docbook
new file mode 100644
index 0000000..96ac1db
--- /dev/null
+++ b/Manuals/TCAR-UG/Docbook/Repository/Convenctions.docbook
@@ -0,0 +1,10 @@
+<chapter id="repo-convs">
+
+ <title>Repository Convenctions</title>
+
+ &repo-layout-filenames;
+ &repo-layout-relbdirs;
+ &repo-layout-syncpaths;
+ &repo-layout-extending;
+
+</chapter>
diff --git a/Manuals/TCAR-UG/Docbook/Repository/Convenctions/extending.docbook b/Manuals/TCAR-UG/Docbook/Repository/Convenctions/extending.docbook
new file mode 100644
index 0000000..d99c721
--- /dev/null
+++ b/Manuals/TCAR-UG/Docbook/Repository/Convenctions/extending.docbook
@@ -0,0 +1,40 @@
+<sect1 id="repo-worklines-extending">
+
+ <title>Extending Repository Layout</title>
+
+ <para>
+ Occasionly, you may find that new components of &TCPCVI; 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 starting to create directories blindly all over, is:
+ <emphasis>What is the right place to store it?</emphasis>
+ </para>
+
+ <para>
+ When the repository structure is extended, it is very useful
+ to bear in mind &TCPCVIS;, &TCM; and &TCDRS;. The rest is a
+ matter of choosing appropriate names. It is also worth to
+ know that each directory in the repository responds to one or
+ more concepts that justify its existence.
+ </para>
+
+ <para>
+ To build a directory structure inside the repository, you need
+ to define the concept behind it first and later create the
+ directory, remembering that there are locations inside the
+ repository that define concepts you probably would prefer to
+ reuse. For example, the <filename
+ class="directory">trunk/Identity/Images/Themes</filename>
+ directory stores artistic motifs of different themes, the
+ <filename
+ class="directory">trunk/Identity/Models/Themes</filename>
+ directory stores design models for themes, the <filename
+ class="directory">trunk/Manuals</filename> directory stores
+ documentation, the <filename
+ class="directory">trunk/L10n</filename> stores translation
+ messages, and the <filename
+ class="directory">trunk/Scripts</filename> stores automation
+ scripts.
+ </para>
+
+</sect1>
diff --git a/Manuals/TCAR-UG/Docbook/Repository/Convenctions/filenames.docbook b/Manuals/TCAR-UG/Docbook/Repository/Convenctions/filenames.docbook
new file mode 100644
index 0000000..6941b4e
--- /dev/null
+++ b/Manuals/TCAR-UG/Docbook/Repository/Convenctions/filenames.docbook
@@ -0,0 +1,27 @@
+<sect1 id="repo-layout-filenames">
+
+ <title>File Names</title>
+
+ <para>
+ Inside &TCAR;, 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>
+
+</sect1>
diff --git a/Manuals/TCAR-UG/Docbook/Repository/Convenctions/layout.docbook b/Manuals/TCAR-UG/Docbook/Repository/Convenctions/layout.docbook
new file mode 100644
index 0000000..33808e5
--- /dev/null
+++ b/Manuals/TCAR-UG/Docbook/Repository/Convenctions/layout.docbook
@@ -0,0 +1,34 @@
+<sect1 id="repo-convs-layout">
+
+ <title>Directories Layout</title>
+
+ <para>
+ The first level of directories in the repository provides
+ organization through a convenctional <quote>trunk</quote>,
+ <quote>branches</quote> and <quote>tags</quote> layout. In
+ this configuration the <filename
+ class="directory">trunk</filename> directory is where main
+ changes take place, the <filename
+ class="directory">tags</filename> directory is where frozen
+ copies of <filename class="directory">trunk</filename> changes
+ are placed in for releasing, and the <filename
+ class="directory">branches</filename> directory is an
+ intermediate place between <filename
+ class="directory">trunk</filename> and <filename
+ class="directory">tags</filename> states where changes take
+ place before being merged into <filename
+ class="directory">trunk</filename> and finally released into
+ <filename class="directory">tags</filename>.
+ </para>
+
+ <para>
+ The second level of directories in the repository provides
+ organization for each work line described in <xref
+ linkend="repo-worklines" />.
+ </para>
+
+ <para>
+ All other subsequent levels of directories in the repository,
+ from third level on, are created to organize specific concepts
+ related to the work line they are in.
+ </para>
diff --git a/Manuals/TCAR-UG/Docbook/Repository/Convenctions/relbdirs.docbook b/Manuals/TCAR-UG/Docbook/Repository/Convenctions/relbdirs.docbook
new file mode 100644
index 0000000..967bb8e
--- /dev/null
+++ b/Manuals/TCAR-UG/Docbook/Repository/Convenctions/relbdirs.docbook
@@ -0,0 +1,123 @@
+<sect1 id="repo-worklines-relbdirs">
+
+ <title>Path Types</title>
+
+ <para>
+ In order for automation scripts to produce content inside a
+ working copy of &TCAR;, it is required that all work lines be
+ related somehow. The relation between work lines is used by
+ automation scripts to know where to retrive the information
+ they need to work with (e.g., input files, translation
+ messages, output locations, etc.). This kind of relation is
+ built using two path constructions known as <emphasis>master
+ paths</emphasis> and <emphasis>auxiliar paths</emphasis>.
+ </para>
+
+ <variablelist>
+ <varlistentry>
+ <term>Master Paths</term>
+ <listitem>
+ <para>
+ A master path refers to a directory inside the repository that
+ contain input files required to produce output files through
+ automation scripts. Examples of master paths inside the
+ repository include:
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ <filename class="directory">trunk/Identity/Models/Brands</filename>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename class="directory">trunk/Manuals/Repository/Docbook</filename>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename class="directory">trunk/Identity/Models/Themes/Default/Distro/5/Anaconda</filename>
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Auxiliar paths</term>
+ <listitem>
+ <para>
+ An auxiliar path refers a directory inside the repository
+ considered auxiliar for the master path. Auxiliar path can be
+ either for output or localization. Assuming the master path
+ provides the input information, the auxiliar paths provide the
+ auxiliar information which describes how and where that input
+ information is rendered by automation scripts. Examples of
+ auxiliar paths inside the repository include:
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ <filename class="directory">trunk/Identity/Images/Brands</filename>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename class="directory">trunk/Manuals/Repository/Docbook/es_ES</filename>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename class="directory">trunk/Locales/Manuals/Repository/Docbook/es_ES</filename>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename class="directory">trunk/Identity/Images/Themes/Flame/3/Distro/5/Anaconda/es_ES</filename>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename class="directory">trunk/Locales/Identity/Models/Default/Distro/5/Anaconda/es_ES</filename>
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ <para>
+ The relationship between master and auxiliar paths is built by
+ combining the second directory level of master paths with
+ directories in the second directory level of repository
+ layout. In the second directory level of repository layout,
+ the <filename class="directory">Identity</filename>, <filename
+ class="directory">Manuals</filename> and <filename
+ class="directory">Scripts</filename> directories are always
+ used to create the master paths and the output auxiliar paths.
+ The <filename class="directory">Locales</filename> directory,
+ on the other hand, is always used to create localization
+ auxiliar paths for all the master paths available under
+ <filename class="directory">Identity</filename>, <filename
+ class="directory">Manuals</filename> and <filename
+ class="directory">Scripts directories</filename>.
+ </para>
+
+ <para>
+ For example, if the <envar>LANG</envar> environment variable
+ is set to <literal>es_ES.UTF-8</literal> and you execute the
+ <function>render</function> functionality of
+ <command>centos-art.sh</command> script with the <filename
+ class="directory">trunk/Manuals/Repository/Docbook</filename>
+ master path as argument, it will produce &TCARUG; in Spanish
+ language using translation messages from <filename
+ class="directory">trunk/Locales/Manuals/Repository/Docbook/es_ES</filename>
+ auxiliar path and saving output files inside <filename
+ class="directory">trunk/Manuals/Repository/Docbook/es_ES</filename>
+ auxiliar path.
+ </para>
+
+</sect1>
diff --git a/Manuals/TCAR-UG/Docbook/Repository/Convenctions/syncpaths.docbook b/Manuals/TCAR-UG/Docbook/Repository/Convenctions/syncpaths.docbook
new file mode 100644
index 0000000..7b4ec2d
--- /dev/null
+++ b/Manuals/TCAR-UG/Docbook/Repository/Convenctions/syncpaths.docbook
@@ -0,0 +1,96 @@
+<sect1 id="repo-worklines-syncpaths">
+
+ <title>Path Syncronization</title>
+
+ <para>
+ Once both master and auxiliar paths have been related in the
+ repository, they shouldn't be changed except you absolutly
+ need to do so. In this cases, when you need to change master
+ or auxiliar paths, it is required that you also change the
+ relation between them so as to retain their bond. This
+ process of keeping master and auxiliar paths
+ <quote>connected</quote> between themselves 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 from, and whatever information you might need to
+ count with. If the relation between master paths and auxiliar
+ paths is lost, there is no way for automation scripts to know
+ where to retrive the information they need to work with or
+ where to store the output information produced from it. Path
+ syncronization is the way we use through to organize and
+ extend the information stored in the repository.
+ </para>
+
+ <para>
+ Path syncronization involves 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 after a file movement.
+ </para>
+
+ <para>
+ The order followed to syncronize path information is very
+ important because the versioned nature of the files we are
+ working with. When a renaming action needs to be performed
+ inside the repository, we avoid making replacements inside
+ files first and file movements later. This would demand 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 files' internal replacements
+ later. This way it is possible to commit both changes as if
+ they were just one.
+ </para>
+
+ <note>
+ <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's commands
+ instead.
+ </para>
+ </note>
+
+ <para>
+ At this moment there is no full implementation of path
+ syncronization process inside <command>centos-art.sh</command>
+ script and it is somthing we need to do oursleves. However,
+ the <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 you can take as
+ reference to implement it in other areas.
+ </para>
+
+ <para>
+ The plan for a full implementation of path syncronization
+ would be to create individual restricted implementations like
+ the one in <quote>texinfo</quote> backend for other areas that
+ demand it and then, create a higher implmentation that
+ combines them all as needed. This way, if we try to rename a
+ repository directory the higher action will define which are
+ all the restricted actions that should be performed in order
+ to make the full path syncronization.
+ </para>
+
+ <para>
+ For example, if the directory we are renaming is a master
+ path, it is required to syncronize the related output and
+ localization auxiliar paths. On the other hand, if the
+ directory we are renaming through full path syncronization is
+ an auxiliar path, it is required to determine first what is
+ the related master path and later, perform the syncronization
+ from master path to auxiliar paths as if the path provided
+ would be the master path not the auxiliar path.
+ </para>
+
+</sect1>
diff --git a/Manuals/TCAR-UG/Docbook/Repository/Copying.docbook b/Manuals/TCAR-UG/Docbook/Repository/Copying.docbook
deleted file mode 100644
index b84487a..0000000
--- a/Manuals/TCAR-UG/Docbook/Repository/Copying.docbook
+++ /dev/null
@@ -1,68 +0,0 @@
-<chapter id="repo-repoconvs-copying">
-
- <title>Copying Conditions</title>
-
- <para>
- &TCAS; uses &TCAR; to implement &TCPCVI;. The implementation
- itself is controlled by the <command>centos-art.sh</command>
- script.
- </para>
-
- <para>
- Both the <command>centos-art.sh</command> script and &TCAR;,
- 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 work
- 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 work or use pieces of it in new free
- works, 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 work 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>
-
-</chapter>
diff --git a/Manuals/TCAR-UG/Docbook/Repository/History.docbook b/Manuals/TCAR-UG/Docbook/Repository/History.docbook
index fc1967d..6292d08 100644
--- a/Manuals/TCAR-UG/Docbook/Repository/History.docbook
+++ b/Manuals/TCAR-UG/Docbook/Repository/History.docbook
@@ -1,6 +1,6 @@
<chapter id="repo-history" xreflabel="History">
- <title>History</title>
+ <title>Repository History</title>
<para>
&TCAR; started at <ulink
diff --git a/Manuals/TCAR-UG/Docbook/Repository/Layout.docbook b/Manuals/TCAR-UG/Docbook/Repository/Layout.docbook
deleted file mode 100644
index 96ac1db..0000000
--- a/Manuals/TCAR-UG/Docbook/Repository/Layout.docbook
+++ /dev/null
@@ -1,10 +0,0 @@
-<chapter id="repo-convs">
-
- <title>Repository Convenctions</title>
-
- &repo-layout-filenames;
- &repo-layout-relbdirs;
- &repo-layout-syncpaths;
- &repo-layout-extending;
-
-</chapter>
diff --git a/Manuals/TCAR-UG/Docbook/Repository/Layout/extending.docbook b/Manuals/TCAR-UG/Docbook/Repository/Layout/extending.docbook
deleted file mode 100644
index d99c721..0000000
--- a/Manuals/TCAR-UG/Docbook/Repository/Layout/extending.docbook
+++ /dev/null
@@ -1,40 +0,0 @@
-<sect1 id="repo-worklines-extending">
-
- <title>Extending Repository Layout</title>
-
- <para>
- Occasionly, you may find that new components of &TCPCVI; 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 starting to create directories blindly all over, is:
- <emphasis>What is the right place to store it?</emphasis>
- </para>
-
- <para>
- When the repository structure is extended, it is very useful
- to bear in mind &TCPCVIS;, &TCM; and &TCDRS;. The rest is a
- matter of choosing appropriate names. It is also worth to
- know that each directory in the repository responds to one or
- more concepts that justify its existence.
- </para>
-
- <para>
- To build a directory structure inside the repository, you need
- to define the concept behind it first and later create the
- directory, remembering that there are locations inside the
- repository that define concepts you probably would prefer to
- reuse. For example, the <filename
- class="directory">trunk/Identity/Images/Themes</filename>
- directory stores artistic motifs of different themes, the
- <filename
- class="directory">trunk/Identity/Models/Themes</filename>
- directory stores design models for themes, the <filename
- class="directory">trunk/Manuals</filename> directory stores
- documentation, the <filename
- class="directory">trunk/L10n</filename> stores translation
- messages, and the <filename
- class="directory">trunk/Scripts</filename> stores automation
- scripts.
- </para>
-
-</sect1>
diff --git a/Manuals/TCAR-UG/Docbook/Repository/Layout/filenames.docbook b/Manuals/TCAR-UG/Docbook/Repository/Layout/filenames.docbook
deleted file mode 100644
index 6941b4e..0000000
--- a/Manuals/TCAR-UG/Docbook/Repository/Layout/filenames.docbook
+++ /dev/null
@@ -1,27 +0,0 @@
-<sect1 id="repo-layout-filenames">
-
- <title>File Names</title>
-
- <para>
- Inside &TCAR;, 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>
-
-</sect1>
diff --git a/Manuals/TCAR-UG/Docbook/Repository/Layout/layout.docbook b/Manuals/TCAR-UG/Docbook/Repository/Layout/layout.docbook
deleted file mode 100644
index 33808e5..0000000
--- a/Manuals/TCAR-UG/Docbook/Repository/Layout/layout.docbook
+++ /dev/null
@@ -1,34 +0,0 @@
-<sect1 id="repo-convs-layout">
-
- <title>Directories Layout</title>
-
- <para>
- The first level of directories in the repository provides
- organization through a convenctional <quote>trunk</quote>,
- <quote>branches</quote> and <quote>tags</quote> layout. In
- this configuration the <filename
- class="directory">trunk</filename> directory is where main
- changes take place, the <filename
- class="directory">tags</filename> directory is where frozen
- copies of <filename class="directory">trunk</filename> changes
- are placed in for releasing, and the <filename
- class="directory">branches</filename> directory is an
- intermediate place between <filename
- class="directory">trunk</filename> and <filename
- class="directory">tags</filename> states where changes take
- place before being merged into <filename
- class="directory">trunk</filename> and finally released into
- <filename class="directory">tags</filename>.
- </para>
-
- <para>
- The second level of directories in the repository provides
- organization for each work line described in <xref
- linkend="repo-worklines" />.
- </para>
-
- <para>
- All other subsequent levels of directories in the repository,
- from third level on, are created to organize specific concepts
- related to the work line they are in.
- </para>
diff --git a/Manuals/TCAR-UG/Docbook/Repository/Layout/relbdirs.docbook b/Manuals/TCAR-UG/Docbook/Repository/Layout/relbdirs.docbook
deleted file mode 100644
index 967bb8e..0000000
--- a/Manuals/TCAR-UG/Docbook/Repository/Layout/relbdirs.docbook
+++ /dev/null
@@ -1,123 +0,0 @@
-<sect1 id="repo-worklines-relbdirs">
-
- <title>Path Types</title>
-
- <para>
- In order for automation scripts to produce content inside a
- working copy of &TCAR;, it is required that all work lines be
- related somehow. The relation between work lines is used by
- automation scripts to know where to retrive the information
- they need to work with (e.g., input files, translation
- messages, output locations, etc.). This kind of relation is
- built using two path constructions known as <emphasis>master
- paths</emphasis> and <emphasis>auxiliar paths</emphasis>.
- </para>
-
- <variablelist>
- <varlistentry>
- <term>Master Paths</term>
- <listitem>
- <para>
- A master path refers to a directory inside the repository that
- contain input files required to produce output files through
- automation scripts. Examples of master paths inside the
- repository include:
-
- <itemizedlist>
- <listitem>
- <para>
- <filename class="directory">trunk/Identity/Models/Brands</filename>
- </para>
- </listitem>
- <listitem>
- <para>
- <filename class="directory">trunk/Manuals/Repository/Docbook</filename>
- </para>
- </listitem>
- <listitem>
- <para>
- <filename class="directory">trunk/Identity/Models/Themes/Default/Distro/5/Anaconda</filename>
- </para>
- </listitem>
- </itemizedlist>
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Auxiliar paths</term>
- <listitem>
- <para>
- An auxiliar path refers a directory inside the repository
- considered auxiliar for the master path. Auxiliar path can be
- either for output or localization. Assuming the master path
- provides the input information, the auxiliar paths provide the
- auxiliar information which describes how and where that input
- information is rendered by automation scripts. Examples of
- auxiliar paths inside the repository include:
-
- <itemizedlist>
- <listitem>
- <para>
- <filename class="directory">trunk/Identity/Images/Brands</filename>
- </para>
- </listitem>
- <listitem>
- <para>
- <filename class="directory">trunk/Manuals/Repository/Docbook/es_ES</filename>
- </para>
- </listitem>
- <listitem>
- <para>
- <filename class="directory">trunk/Locales/Manuals/Repository/Docbook/es_ES</filename>
- </para>
- </listitem>
- <listitem>
- <para>
- <filename class="directory">trunk/Identity/Images/Themes/Flame/3/Distro/5/Anaconda/es_ES</filename>
- </para>
- </listitem>
- <listitem>
- <para>
- <filename class="directory">trunk/Locales/Identity/Models/Default/Distro/5/Anaconda/es_ES</filename>
- </para>
- </listitem>
- </itemizedlist>
-
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
-
- <para>
- The relationship between master and auxiliar paths is built by
- combining the second directory level of master paths with
- directories in the second directory level of repository
- layout. In the second directory level of repository layout,
- the <filename class="directory">Identity</filename>, <filename
- class="directory">Manuals</filename> and <filename
- class="directory">Scripts</filename> directories are always
- used to create the master paths and the output auxiliar paths.
- The <filename class="directory">Locales</filename> directory,
- on the other hand, is always used to create localization
- auxiliar paths for all the master paths available under
- <filename class="directory">Identity</filename>, <filename
- class="directory">Manuals</filename> and <filename
- class="directory">Scripts directories</filename>.
- </para>
-
- <para>
- For example, if the <envar>LANG</envar> environment variable
- is set to <literal>es_ES.UTF-8</literal> and you execute the
- <function>render</function> functionality of
- <command>centos-art.sh</command> script with the <filename
- class="directory">trunk/Manuals/Repository/Docbook</filename>
- master path as argument, it will produce &TCARUG; in Spanish
- language using translation messages from <filename
- class="directory">trunk/Locales/Manuals/Repository/Docbook/es_ES</filename>
- auxiliar path and saving output files inside <filename
- class="directory">trunk/Manuals/Repository/Docbook/es_ES</filename>
- auxiliar path.
- </para>
-
-</sect1>
diff --git a/Manuals/TCAR-UG/Docbook/Repository/Layout/syncpaths.docbook b/Manuals/TCAR-UG/Docbook/Repository/Layout/syncpaths.docbook
deleted file mode 100644
index 7b4ec2d..0000000
--- a/Manuals/TCAR-UG/Docbook/Repository/Layout/syncpaths.docbook
+++ /dev/null
@@ -1,96 +0,0 @@
-<sect1 id="repo-worklines-syncpaths">
-
- <title>Path Syncronization</title>
-
- <para>
- Once both master and auxiliar paths have been related in the
- repository, they shouldn't be changed except you absolutly
- need to do so. In this cases, when you need to change master
- or auxiliar paths, it is required that you also change the
- relation between them so as to retain their bond. This
- process of keeping master and auxiliar paths
- <quote>connected</quote> between themselves 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 from, and whatever information you might need to
- count with. If the relation between master paths and auxiliar
- paths is lost, there is no way for automation scripts to know
- where to retrive the information they need to work with or
- where to store the output information produced from it. Path
- syncronization is the way we use through to organize and
- extend the information stored in the repository.
- </para>
-
- <para>
- Path syncronization involves 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 after a file movement.
- </para>
-
- <para>
- The order followed to syncronize path information is very
- important because the versioned nature of the files we are
- working with. When a renaming action needs to be performed
- inside the repository, we avoid making replacements inside
- files first and file movements later. This would demand 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 files' internal replacements
- later. This way it is possible to commit both changes as if
- they were just one.
- </para>
-
- <note>
- <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's commands
- instead.
- </para>
- </note>
-
- <para>
- At this moment there is no full implementation of path
- syncronization process inside <command>centos-art.sh</command>
- script and it is somthing we need to do oursleves. However,
- the <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 you can take as
- reference to implement it in other areas.
- </para>
-
- <para>
- The plan for a full implementation of path syncronization
- would be to create individual restricted implementations like
- the one in <quote>texinfo</quote> backend for other areas that
- demand it and then, create a higher implmentation that
- combines them all as needed. This way, if we try to rename a
- repository directory the higher action will define which are
- all the restricted actions that should be performed in order
- to make the full path syncronization.
- </para>
-
- <para>
- For example, if the directory we are renaming is a master
- path, it is required to syncronize the related output and
- localization auxiliar paths. On the other hand, if the
- directory we are renaming through full path syncronization is
- an auxiliar path, it is required to determine first what is
- the related master path and later, perform the syncronization
- from master path to auxiliar paths as if the path provided
- would be the master path not the auxiliar path.
- </para>
-
-</sect1>
diff --git a/Manuals/TCAR-UG/Docbook/Repository/Worklines.docbook b/Manuals/TCAR-UG/Docbook/Repository/Worklines.docbook
index c32065a..cf805a6 100644
--- a/Manuals/TCAR-UG/Docbook/Repository/Worklines.docbook
+++ b/Manuals/TCAR-UG/Docbook/Repository/Worklines.docbook
@@ -1,6 +1,6 @@
<chapter id="repo-worklines">
- <title>Work Lines</title>
+ <title>Identifying Repository's Work Lines</title>
<para>
To organize content production inside &TCAR;, production has
diff --git a/Manuals/TCAR-UG/Docbook/Repository/Workstation.docbook b/Manuals/TCAR-UG/Docbook/Repository/Workstation.docbook
new file mode 100644
index 0000000..66b07de
--- /dev/null
+++ b/Manuals/TCAR-UG/Docbook/Repository/Workstation.docbook
@@ -0,0 +1,9 @@
+<chapter id="repo-ws">
+
+ <title>Preparing Your Workstation</title>
+
+ &repo-ws-overview;
+ &repo-ws-install;
+ &repo-ws-config;
+
+</chapter>
diff --git a/Manuals/TCAR-UG/Docbook/Repository/Workstation/config.docbook b/Manuals/TCAR-UG/Docbook/Repository/Workstation/config.docbook
new file mode 100644
index 0000000..2afdab5
--- /dev/null
+++ b/Manuals/TCAR-UG/Docbook/Repository/Workstation/config.docbook
@@ -0,0 +1,389 @@
+<sect1 id="repo-ws-configure">
+
+ <title>Configuring Your Workstation</title>
+
+ <para>
+ Once your worstation is installed, it is time for you to
+ configure it. At this point you create a user for everyday's
+ work, configure third party repositories, fix environment
+ variables to fit your personal needs, download the working
+ copy of &TCAR; and prepare it for start using it.
+ </para>
+
+ <sect2 id="repo-ws-configure-wp">
+
+ <title>The Workplace</title>
+
+ <para>
+ Once you've installed the workstation and it is up and
+ running, you need to create the user name you'll use for your
+ everyday's work. In this task you need to use the commands
+ <command>useradd</command> and <command>passwd</command> to
+ create the user name and set a password for it, respectively.
+ These commands require administrative privileges to be
+ executed, so you need to login as <emphasis>root</emphasis>
+ superuser for doing so.
+ </para>
+
+ <caution>
+ <para>
+ Do not use the <emphasis>root</emphasis> username for your
+ everyday's work inside your working copy of &TCAR;. This is
+ dangerous and might provoke unreversable damages on your
+ workstation.
+ </para>
+ </caution>
+
+ <para>
+ When user names are created inside the workstation, it doesn't
+ create only a user identifier for you to login, but a place
+ for you to store your information, as well. This place is
+ known as your home directory and is unique for each user
+ inside the workstation. At the moment, we face the following
+ design problems related to handling absolute paths inside the
+ working copies of &TCAR;:
+ </para>
+
+ <variablelist>
+ <varlistentry>
+ <term>Case 1: Different home directories</term>
+ <listitem>
+ <para>
+ Assuming you store your working copy under <filename
+ class="directory">/home/john/artwork/</filename> and I store
+ mine under <filename
+ class="directory">/home/al/artwork/</filename>, we'll end up
+ refering the same files inside our working copies through
+ different absolute paths. This generates a contradiction when
+ files, holding path information inside, are committed up to
+ the central repository. The contradiction comes from the
+ question: which is the correct absolute path to use inside
+ such files, yours or mine? — No one of them is, of
+ course.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Case 2: One unique home directory</term>
+ <listitem>
+ <para>
+ Another case would be that you and I ourselves use one unique
+ home directory (e.g., <filename
+ class="directory">/home/centos/artwork/</filename>) to store
+ the working copy of &TCAR; in our own workstations, but
+ configure the subversion client to use different user names to
+ commit changes up from the working copy to the central
+ repository. This configuration might be not so good for
+ situations where you and I have to share the same workstation.
+ In such case, it would be required that we both share the
+ password information of the same system user (the
+ <emphasis>centos</emphasis> user in our example) which, in
+ addition, gives access to that user's subversion client
+ configuration and this way provokes the whole sense of using
+ different subversion credentials for committing changes to be
+ lost.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Case 3: Different home directories through dynamic expansion</term>
+ <listitem>
+ <para>
+ Most of the absolute paths we use inside the working copy are
+ made of two parts, one dynamic and one fixed. The dynamic part
+ is the home directory of the current user and its value can be
+ retrived from the <envar>$HOME</envar> environment variable.
+ The fixed part of the path is the one we set inside the
+ repositroy structure itself as organization matter. What we
+ need here is to find a way to expand variables inside files
+ that don't support variable expansion. So far we've been
+ doing this through creation template instances which are
+ temporal files with translation markers expanded inside. This
+ work rather fine with template files that are one-time-pass
+ (e.g., when we produce produce PNG files from SVG files and
+ XTHML from DocBook files), but the same is not true for
+ absolute paths inside files that are used as in their
+ permanent state inside the repository (e.g., CSS files and
+ other files similar in purpose).
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ <para>
+ From the three cases discussed above, the second one (i.e.,
+ One unique home directory) seems to be the best candidate. It
+ limits us from using more than one working copy in the same
+ workstation, but gives us the chance of standardizing the use
+ of absolute paths inside all the working copies of &TCAR;.
+ Using absolute paths is very convenient because it is possible
+ to reuse information from different locations inside the
+ working copy, something that would be almost imposible to
+ maintain if relative paths were used instead. Thus, lets
+ assume the second case of handling home directories as default
+ solution to relatively solve the problem of where to store
+ working copies of &TCAR; until a better one shows itself up.
+ </para>
+
+ <para>
+ The action of providing working copies of &TCAR; that permit
+ to reuse files inside them unifies the way content is produced
+ inside the working copy and provides a convenction for people
+ working on different areas to get attached to in order to
+ syncronize their works and still keep doing it decentralized
+ one another.
+ </para>
+
+ </sect2>
+
+ <sect2>
+ <title>The Environment Variables</title>
+
+ <para>
+ Once you've created the <emphasis>centos</emphasis> user name
+ for your everyday's work and you had done login with it, there
+ are some environment variables that you can customize to fit
+ your personal needs (e.g., default text editor, default locale
+ information, default time zone representation, etc.). To
+ customize these variables you need to edit your personal
+ profile (i.e., <filename
+ class="directory">~/.bash_profile</filename>) and set the
+ redefinition there. Notice that you may need to logout and
+ then do login again in order for the new variable values to
+ take effect.
+ </para>
+
+ <variablelist>
+ <varlistentry>
+ <term>Default text editor</term>
+ <listitem>
+ <para>
+ The default text editor information is controlled by the
+ <envar>EDITOR</envar> environment variable. The
+ <command>centos-art.sh</command> script uses the default text
+ editor to edit subversion pre-commit messages, translation
+ files, documentation files, script files, and similar
+ text-based files.
+ </para>
+
+ <para>
+ If <envar>EDITOR</envar> environment variable is not set,
+ <command>centos-art.sh</command> script uses <filename
+ class="directory">/usr/bin/vim</filename> as default text
+ editor. Otherwise, the following values are recognized by
+ <command>centos-art.sh</command> script:
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ <filename class="directory">/usr/bin/vim</filename>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <filename class="directory">/usr/bin/emacs</filename>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <filename class="directory">/usr/bin/nano</filename>
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ </para>
+
+ <para>
+ If no one of these values is set in the <envar>EDITOR</envar>
+ environment variable, the <command>centos-art.sh</command>
+ script uses <filename
+ class="directory">/usr/bin/vim</filename> text editor, the one
+ installed by default in &TCD;.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Default locale information</term>
+ <listitem>
+ <para>
+ The default locale information is controlled by the
+ <envar>LANG</envar> environment variable. This variable is
+ initially set in the installation process of &TCD;,
+ specifically in the <emphasis>Language</emphasis> step.
+ Generally, there is no need to customize this variable in your
+ personal profile. If you need to change the value of this
+ environment variable do it through the login screen of GNOME
+ Desktop Environment or the
+ <command>system-config-language</command> command.
+ </para>
+
+ <para>
+ The <command>centos-art.sh</command> script uses the
+ <envar>LANG</envar> environment variable to determine what
+ language to use for printing output messages from the script
+ itself, as well as the portable objects locations that need to
+ be updated or edited when you localize directory structures
+ inside the working copy of &TCAR;.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Default time zone representation</term>
+ <listitem>
+ <para>
+ The time zone representation is a time correction applied to
+ the system time (stored in the BIOS clock) based on your
+ country location. This correction is specially useful to
+ distributed computers around the world that work together and
+ need to be syncronized in time to know when things happened.
+ </para>
+ <para>
+ &TCAR; is made of one server and several workstations spread
+ around the world. In order for all these workstations to know
+ when changes in the server took place, it is required that
+ they all set their system clocks to use the same time
+ information (e.g., through UTC (Coordinated Universal Time))
+ and set the time correction for their specific countries in
+ the operating system. Otherwise, it would be difficult to
+ know when something exactly happened.
+ </para>
+ <para>
+ Generally, setting the time information is a straight-forward
+ task and configuration tools provided by &TCD; do cover time
+ correction for most of the countries around the world.
+ However, if you need a time precision not provided by any of
+ the date and time configuration tools provided by &TCD; then,
+ you need to customize the <envar>TZ</envar> environment
+ variable in your personal profile to correct the time
+ information by yourself. The format of <envar>TZ</envar>
+ environment variable is described in <code>tzset(3)</code>
+ manual page.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </sect2>
+
+ <sect2>
+ <title>The Administrative Tasks</title>
+
+ <para>
+ Sometimes it is necessary that you perform administrative
+ tasks inside the workstation the working copy of &TCAR; is
+ stored in. These tasks might demand you to type many commands
+ (e.g., for configuring a third party repository) or just a
+ one-line command (e.g., for installing a new package). In
+ both cases this kind of tasks require permissions that your
+ user for everyday's work must not have under no mean.
+ </para>
+
+ <para>
+ To perform administrative tasks in your workstation, you need
+ to login as <emphasis>root</emphasis> or configure the
+ <command>sudo</command> program to temporarily granting the
+ permissions your regular user needs to perform the
+ administrative tasks. The configuration of
+ <command>sudo</command> program is at
+ <filename>/etc/sudoers</filename> file and you need to add the
+ <emphasis>centos</emphasis> user to the list of privileged
+ user as described in the section below:
+ </para>
+
+<screen>
+## Next comes the main part: which users can run what software on
+## which machines (the sudoers file can be shared between multiple
+## systems).
+## Syntax:
+##
+## user MACHINE=COMMANDS
+##
+## The COMMANDS section may have other options added to it.
+##
+## Allow root to run any commands anywhere
+root ALL=(ALL) ALL
+centos ALL=(ALL) ALL
+</screen>
+
+ <para>
+ This configuration is required in order for automation scripts
+ to realize administrative tasks that otherwise you would need
+ to type one by one. It is worth to mention that all these
+ tasks are organized in the <function>prepare</function>
+ functionality of the <command>centos-art.sh</command> script
+ in the sake of reducing work and standardize the procedure of
+ performing them. It is also worth to mention that, the
+ <command>centos-art.sh</command> script is available for you
+ to run, study, improve and share your changes as described in
+ <xref linkend="licenses-gpl" />.
+ </para>
+
+ </sect2>
+
+ <sect2>
+ <title>The Working Copy</title>
+
+ <para>
+ Once you've installed and configured the workstation, it is
+ ready to receive the working copy of &TCAR;. In this step, you
+ use Subversion's client to communicate the source repository
+ of &TCAR; and download the files that make a working copy of
+ it so you can change and receive changes from others.
+ </para>
+
+ <para>
+ To download the working copy of &TCAR; you need to login as
+ your everyday's work user (i.e., the
+ <emphasis>centos</emphasis> user) and use the Subversion
+ client installed in your workstation to bring all the files
+ you need to work with from the source repository down to your
+ workstation, just as the following command describes:
+ </para>
+
+ <screen>svn co https://projects.centos.org/svn/artwork ~/</screen>
+
+ <para>
+ This command will create your working copy of &TCAR; in your
+ workstation, specifically in the <filename
+ class="directory">/home/centos/artwork</filename> directory.
+ </para>
+
+ <para>
+ If the Subversion's client wasn't installed by default, you
+ need to install it using the following command:
+ </para>
+
+ <screen>sudo yum install subversion</screen>
+
+ <para>
+ Once your working copy of &TCAR; has been downloaded, the
+ first thing you need to do with it is preparing it. In this
+ step you prepare the working copy to start working with it. By
+ default the working copy only provides the source files used
+ to produce documentation translations, and images. So it is
+ necessary that you render all this content in order to have
+ something to work with. Additionally, it is also necessary to
+ verify software packages and create the symbolic links that
+ connect the content produced inside the working copy to
+ applications outside it (e.g., to make available patterns,
+ brushes, and palettes produced inside the working copy in
+ GIMP, the application used to manipulate images).
+ </para>
+
+ <para>
+ In order to standardize all these preparation stuff, the
+ <command>centos-art.sh</command> script provides the
+ <function>prepare</function> functionality as described in
+ <xref linkend="scripts-bash-prepare" />. Execute it right now,
+ to be sure your workstation and your working copy are both
+ ready to be used.
+ </para>
+
+ </sect2>
+
+</sect1>
diff --git a/Manuals/TCAR-UG/Docbook/Repository/Workstation/install.docbook b/Manuals/TCAR-UG/Docbook/Repository/Workstation/install.docbook
new file mode 100644
index 0000000..577250c
--- /dev/null
+++ b/Manuals/TCAR-UG/Docbook/Repository/Workstation/install.docbook
@@ -0,0 +1,221 @@
+<sect1 id="repo-ws-install">
+
+ <title>Installing Your Workstation</title>
+
+ <para>
+ In order to have a working copy of &TCAR; in your workstation,
+ the first step you need to follow is pick up a computer and
+ install an operating system in it. This computer will be named
+ the workstation from now on.
+ </para>
+
+ <para>
+ At the moment of chosing which operating system to install in
+ your workstation, consider that &TCAR; is completly built on
+ &TCD; and realies on it to achieve most automation tasks. At
+ time of this writing the major release 5 update 5 of &TCD; was
+ used as platform to support all work line development inside
+ &TCAR;. To get the best of &TCAR;, it is necessary that you
+ too, use the same operating system we did to develop it.
+ </para>
+
+ <para>
+ To install &TCD; you need to have access to the installation
+ media somehow (e.g., CDs, DVDs, Pendrives, etc.). If you
+ don't have the installation media of &TCD;, you need to
+ download the ISO files related to the installation media you
+ plan to use (e.g., CD or DVD) and then create the installation
+ media by yourself. &TCD; ISO files can be downloaded from
+ &TCM;.
+ </para>
+
+ <para>
+ Assuming you downloaded the DVD ISO of &TCD;, you can burn it
+ using the <application>K3B</application> application and, this
+ way, you are creating the installation media you are in need
+ of. Of course, in order to download the ISO files and create
+ the installation media, you need to have a workstation already
+ functionality where you can realized such tasks. If this is
+ the first time for you and see yourself into much troubles
+ here, talk to the guys in your nearest LUG, or simply send a
+ mail to &TCML; where you'll surely have the answer you need.
+ </para>
+
+ <para>
+ Once you have the installation media on your hands, the
+ installation process of &TCD; is rather straightforward. To
+ begin, you put the installation media in your media reader,
+ boot the computer from it, and follow the installer
+ intructions till it completes all the steps. That simple.
+ </para>
+
+ <sect2 id="repo-ws-partition">
+
+ <title>The Partition Information</title>
+
+ <para>
+ The partition information you set in your workstation is very
+ specific to your personal needs and the technical
+ characteristics of your machine. This information will also
+ set the bases of all deployment you reach to achieve inside
+ the workstation. A well partitioned workstation is crucial to
+ garantee a well distribution of space inside the worstation.
+ In order to provide an idea of this installation step, I'll
+ describe the specific partitioning of the machine I use to
+ develop &TCAR; right now. Remember that your needs might be
+ differents and so the partition layout you should implement.
+ </para>
+
+ <para>
+ The machine of our example is isolated from Internet or any
+ other network. It has two hard drives of 256GB each, 2GB of
+ RAM and a 2.80GHz Core 2 Duo processor. The main goal of this
+ machine is producing &TCAR;. To represent the real production
+ environment of &TCAR;, this machine was conceived to have two
+ roles, one as server —to store the source repository of
+ &TCAR;— and one as client —to store a working copy
+ of the source repository—. From both hard drives
+ available, one is used as primary
+ (<filename>/dev/sda</filename>) and the other one as secondary
+ (<filename>/dev/sdb</filename>) where the secondary is used
+ only to backup the information produced in the primary by mean
+ of backup scripts.
+ </para>
+ <para>
+ The partition distribution of this machine implements the
+ default partinioning schema provided by &TCD; in the primary
+ hard drive to store partitions needed by the operating system
+ (e.g., <filename class="directory">/</filename>, <filename
+ class="directory">/boot</filename> and swap partition) where
+ the working copy is placed in. The second hard drive is an
+ entire partition mounted in <filename
+ class="directory">/mnt/backups</filename> automatically on
+ boot which only purpose is to duplicate the information
+ produced in the workplace.
+ </para>
+
+<screen>
+Filesystem Type Size Mounted on
+/dev/mapper/VolGroup00-LogVol00 ext3 239G /
+/dev/sda1 ext3 104M /boot
+tmpfs tmpfs 1.1G /dev/shm
+/dev/sdb ext3 247G /mnt/backups
+</screen>
+
+ <para>
+ The detailed steps followed to prepare the partinioning layout
+ described above are described in the <citetitle>Deployment
+ Guide</citetitle> provided by
+ <package>Deployment_Guide-en-US-5.2-11.el5.centos</package>
+ package.
+ </para>
+
+ </sect2>
+
+ <sect2 id="repo-ws-packages">
+
+ <title>The Packages Selection</title>
+
+ <para>
+ The packages selection lets you to specify which software does
+ your workstation will have once it be installed. In this step,
+ you need to select the following groups of packages:
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>Desktop Environments</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ GNOME Desktop Environment
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ KDE (K Desktop Environment)
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+
+ <listitem>
+ <para>Applications</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Authoring and Publishing
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Editors
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Graphical Internet
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Graphics
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Office/Productivity
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Text-based Internet
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+
+ <listitem>
+ <para>Development</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Development Libraries
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Development Tools
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ GNOME Software Development
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ KDE Software Development
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ </itemizedlist>
+
+ <para>
+ Packages selected in this step provide a base selection of all
+ the packages you need in order to have a functional working
+ copy of &TCAR;. The only exception for this, is the
+ <package>inkscape</package> package and some of its
+ dependencies which doesn't come with &TCD; and need to be
+ installed from third party repositroies like EPEL and
+ RPMForge. The configuration of third party repository is done
+ later, once the workstation has been installed; just as
+ described in the <ulink
+ url="http://wiki.centos.org/AdditionalResources/Repositories">Repositories</ulink>
+ page.
+ </para>
+
+ </sect2>
+
+</sect1>
diff --git a/Manuals/TCAR-UG/Docbook/Repository/Workstation/overview.docbook b/Manuals/TCAR-UG/Docbook/Repository/Workstation/overview.docbook
new file mode 100644
index 0000000..ca68a42
--- /dev/null
+++ b/Manuals/TCAR-UG/Docbook/Repository/Workstation/overview.docbook
@@ -0,0 +1,27 @@
+<sect1 id="repo-ws-overview">
+
+ <title>Overview</title>
+
+ <para>
+ The workstation is the machine you use to store your working
+ copy of &TCAR;. The working copy is an ordinary directory
+ tree on your workstation, containing a collection of files
+ that you can edit however you wish. It is your own private
+ work area related to &TCAR;. It is the place where you perform
+ changes and receive changes from others.
+ </para>
+
+ <para>
+ In order to make your workstation completely functional, it is
+ necessary that you install it and configure it to satisfy the
+ needs demanded by the working copy of &TCAR; you lately
+ download in it.
+ </para>
+
+ <para>
+ This chapter describes the steps you need to follow in order
+ to install and configure a workstation for using a working
+ copy of &TCAR; in all its extention.
+ </para>
+
+</sect1>
diff --git a/Manuals/TCAR-UG/Docbook/Scripts/Bash/help.docbook b/Manuals/TCAR-UG/Docbook/Scripts/Bash/help.docbook
index 531b199..91c480b 100644
--- a/Manuals/TCAR-UG/Docbook/Scripts/Bash/help.docbook
+++ b/Manuals/TCAR-UG/Docbook/Scripts/Bash/help.docbook
@@ -16,9 +16,7 @@
<title>Synopsis</title>
- <para>
- <userinput>centos-art help [OPTIONS] path/to/dir …</userinput>
- </para>
+ <screen>centos-art help [OPTIONS] path/to/dir ...</screen>
<para>
The <parameter>path/to/dir</parameter> parameter specifies
diff --git a/Manuals/TCAR-UG/Docbook/Scripts/Bash/prepare.docbook b/Manuals/TCAR-UG/Docbook/Scripts/Bash/prepare.docbook
index f518855..b643613 100644
--- a/Manuals/TCAR-UG/Docbook/Scripts/Bash/prepare.docbook
+++ b/Manuals/TCAR-UG/Docbook/Scripts/Bash/prepare.docbook
@@ -1,4 +1,40 @@
<sect1 id="scripts-bash-prepare">
<title>The <function>prepare</function> functionality</title>
- <para>...</para>
+
+ <para>
+ Assuming this is the very first time you run the
+ <command>centos-art.sh</command> script, you'll find that
+ it isn't found in your workstation. This is correct because
+ you haven't create the command-line interface symbolic link
+ that make it available in the execution path. In order to make
+ the <command>centos-art.sh</command> command-line
+ available in the execution path of your workstation, you need
+ to run it using its absolute path first:
+ </para>
+
+ <screen>~/artwork/trunk/Scripts/centos-art.sh prepare [OPTIONS]</screen>
+
+ <para>
+ Later, once the <command>centos-art.sh</command> script is
+ available in the execution path of your system, there is no
+ need for you to use the absolute path again. From this time
+ on, you can use the <command>centos-art</command> command-line
+ interface directly, as the following example describes:
+ </para>
+
+ <screen>centos-art prepare [OPTIONS]</screen>
+
+ <para>
+ Notice that you can execute the prepare functionality more
+ than once. This is specially useful to keep the link
+ information syncronized. For example, considering you've added
+ new brushes to or removed old brushes from your working copy
+ of &TCAR;, the link information related to those files need to
+ be updated in the <filename
+ class="directory">~/.gimp-2.2/brushes</filename> directory
+ too, in a way the addition/deletion change that took place in
+ your working copy can be reflected there, as well. The same
+ is true for other similar components like fonts, patterns and
+ palettes.
+ </para>
</sect1>