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 @@
+&TC; Mirrors">
@@ -36,7 +37,9 @@
&TCA; Mailing List">
&TC; Developers Mailing List">
+&TC; Mailing List">
+&TC; Documentation">
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 @@
Repository
- &repo-history;
- &repo-copying;
- &repo-usage;
- &repo-worklines;
&repo-layout;
+ &repo-whatis;
+ &repo-ws;
+ &repo-worklines;
+ &repo-history;
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 @@
-
+
-
-
-
-
+
+
+
+
-
-
+
+
+
+
+
-
+
+
+
+
-
-
-
-
-
-
+
+
+
+
+
-
+
+
+
+
-
-
-
-
-
-
-
+
+
+
+
+
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 @@
+
+
+ Repository Convenctions
+
+ &repo-layout-filenames;
+ &repo-layout-relbdirs;
+ &repo-layout-syncpaths;
+ &repo-layout-extending;
+
+
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 @@
+
+
+ Extending Repository Layout
+
+
+ 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:
+ What is the right place to store it?
+
+
+
+ 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.
+
+
+
+ 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 trunk/Identity/Images/Themes
+ directory stores artistic motifs of different themes, the
+ trunk/Identity/Models/Themes
+ directory stores design models for themes, the trunk/Manuals directory stores
+ documentation, the trunk/L10n stores translation
+ messages, and the trunk/Scripts stores automation
+ scripts.
+
+
+
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 @@
+
+
+ File Names
+
+
+ Inside &TCAR;, file names are all written in lowercase (e.g.,
+ 01-welcome.png,
+ splash.png,
+ anaconda_header.png, etc.) and directory
+ names are all written capitalized (e.g., Identity, Themes, Motifs) and sometimes in cammel
+ case (e.g., TreeFlower,
+ etc.).
+
+
+
+ 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.
+
+
+
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 @@
+
+
+ Directories Layout
+
+
+ The first level of directories in the repository provides
+ organization through a convenctional trunk,
+ branches and tags layout. In
+ this configuration the trunk directory is where main
+ changes take place, the tags directory is where frozen
+ copies of trunk changes
+ are placed in for releasing, and the branches directory is an
+ intermediate place between trunk and tags states where changes take
+ place before being merged into trunk and finally released into
+ tags.
+
+
+
+ The second level of directories in the repository provides
+ organization for each work line described in .
+
+
+
+ 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.
+
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 @@
+
+
+ Path Types
+
+
+ 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 master
+ paths and auxiliar paths.
+
+
+
+
+ Master Paths
+
+
+ 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:
+
+
+
+
+ trunk/Identity/Models/Brands
+
+
+
+
+ trunk/Manuals/Repository/Docbook
+
+
+
+
+ trunk/Identity/Models/Themes/Default/Distro/5/Anaconda
+
+
+
+
+
+
+
+
+ Auxiliar paths
+
+
+ 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:
+
+
+
+
+ trunk/Identity/Images/Brands
+
+
+
+
+ trunk/Manuals/Repository/Docbook/es_ES
+
+
+
+
+ trunk/Locales/Manuals/Repository/Docbook/es_ES
+
+
+
+
+ trunk/Identity/Images/Themes/Flame/3/Distro/5/Anaconda/es_ES
+
+
+
+
+ trunk/Locales/Identity/Models/Default/Distro/5/Anaconda/es_ES
+
+
+
+
+
+
+
+
+
+
+ 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 Identity, Manuals and Scripts directories are always
+ used to create the master paths and the output auxiliar paths.
+ The Locales directory,
+ on the other hand, is always used to create localization
+ auxiliar paths for all the master paths available under
+ Identity, Manuals and Scripts directories.
+
+
+
+ For example, if the LANG environment variable
+ is set to es_ES.UTF-8 and you execute the
+ render functionality of
+ centos-art.sh script with the trunk/Manuals/Repository/Docbook
+ master path as argument, it will produce &TCARUG; in Spanish
+ language using translation messages from trunk/Locales/Manuals/Repository/Docbook/es_ES
+ auxiliar path and saving output files inside trunk/Manuals/Repository/Docbook/es_ES
+ auxiliar path.
+
+
+
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 @@
+
+
+ Path Syncronization
+
+
+ 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
+ connected between themselves is known as
+ path syncronization.
+
+
+
+ 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.
+
+
+
+ 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.
+
+
+
+ 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.
+
+
+
+
+ There is no support for URLs actions inside
+ centos-art.sh script. The
+ centos-art.sh 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.
+
+
+
+
+ At this moment there is no full implementation of path
+ syncronization process inside centos-art.sh
+ script and it is somthing we need to do oursleves. However,
+ the texinfo backend of help
+ functionality which provides a restricted implementation of
+ path syncronization to this specific area of documentation
+ through the ,
+ and options you can take as
+ reference to implement it in other areas.
+
+
+
+ The plan for a full implementation of path syncronization
+ would be to create individual restricted implementations like
+ the one in texinfo 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.
+
+
+
+ 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.
+
+
+
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 @@
-
-
- Copying Conditions
-
-
- &TCAS; uses &TCAR; to implement &TCPCVI;. The implementation
- itself is controlled by the centos-art.sh
- script.
-
-
-
- Both the centos-art.sh 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.
-
-
-
- Specifically, we want to make sure that you have the right to
- give away copies of centos-art.sh 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.
-
-
-
- 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 centos-art.sh
- 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.
-
-
-
- Also, for our own protection, we must make certain that
- everyone finds out that there is no warranty for the
- centos-art.sh 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.
-
-
-
- The centos-art.sh script is released as a
- GPL work. Individual packages used by
- centos-art.sh script include their own
- licenses and the centos-art.sh script
- license applies to all packages that it does not clash with.
- If there is a clash between the
- centos-art.sh script license and individual
- package licenses, the individual package license applies
- instead.
-
-
-
- The precise conditions of the license for the
- centos-art.sh script are found in the . This manual specifically is covered
- by the .
-
-
-
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 @@
- History
+ Repository History
&TCAR; started at
-
- Repository Convenctions
-
- &repo-layout-filenames;
- &repo-layout-relbdirs;
- &repo-layout-syncpaths;
- &repo-layout-extending;
-
-
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 @@
-
-
- Extending Repository Layout
-
-
- 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:
- What is the right place to store it?
-
-
-
- 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.
-
-
-
- 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 trunk/Identity/Images/Themes
- directory stores artistic motifs of different themes, the
- trunk/Identity/Models/Themes
- directory stores design models for themes, the trunk/Manuals directory stores
- documentation, the trunk/L10n stores translation
- messages, and the trunk/Scripts stores automation
- scripts.
-
-
-
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 @@
-
-
- File Names
-
-
- Inside &TCAR;, file names are all written in lowercase (e.g.,
- 01-welcome.png,
- splash.png,
- anaconda_header.png, etc.) and directory
- names are all written capitalized (e.g., Identity, Themes, Motifs) and sometimes in cammel
- case (e.g., TreeFlower,
- etc.).
-
-
-
- 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.
-
-
-
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 @@
-
-
- Directories Layout
-
-
- The first level of directories in the repository provides
- organization through a convenctional trunk,
- branches and tags layout. In
- this configuration the trunk directory is where main
- changes take place, the tags directory is where frozen
- copies of trunk changes
- are placed in for releasing, and the branches directory is an
- intermediate place between trunk and tags states where changes take
- place before being merged into trunk and finally released into
- tags.
-
-
-
- The second level of directories in the repository provides
- organization for each work line described in .
-
-
-
- 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.
-
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 @@
-
-
- Path Types
-
-
- 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 master
- paths and auxiliar paths.
-
-
-
-
- Master Paths
-
-
- 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:
-
-
-
-
- trunk/Identity/Models/Brands
-
-
-
-
- trunk/Manuals/Repository/Docbook
-
-
-
-
- trunk/Identity/Models/Themes/Default/Distro/5/Anaconda
-
-
-
-
-
-
-
-
- Auxiliar paths
-
-
- 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:
-
-
-
-
- trunk/Identity/Images/Brands
-
-
-
-
- trunk/Manuals/Repository/Docbook/es_ES
-
-
-
-
- trunk/Locales/Manuals/Repository/Docbook/es_ES
-
-
-
-
- trunk/Identity/Images/Themes/Flame/3/Distro/5/Anaconda/es_ES
-
-
-
-
- trunk/Locales/Identity/Models/Default/Distro/5/Anaconda/es_ES
-
-
-
-
-
-
-
-
-
-
- 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 Identity, Manuals and Scripts directories are always
- used to create the master paths and the output auxiliar paths.
- The Locales directory,
- on the other hand, is always used to create localization
- auxiliar paths for all the master paths available under
- Identity, Manuals and Scripts directories.
-
-
-
- For example, if the LANG environment variable
- is set to es_ES.UTF-8 and you execute the
- render functionality of
- centos-art.sh script with the trunk/Manuals/Repository/Docbook
- master path as argument, it will produce &TCARUG; in Spanish
- language using translation messages from trunk/Locales/Manuals/Repository/Docbook/es_ES
- auxiliar path and saving output files inside trunk/Manuals/Repository/Docbook/es_ES
- auxiliar path.
-
-
-
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 @@
-
-
- Path Syncronization
-
-
- 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
- connected between themselves is known as
- path syncronization.
-
-
-
- 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.
-
-
-
- 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.
-
-
-
- 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.
-
-
-
-
- There is no support for URLs actions inside
- centos-art.sh script. The
- centos-art.sh 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.
-
-
-
-
- At this moment there is no full implementation of path
- syncronization process inside centos-art.sh
- script and it is somthing we need to do oursleves. However,
- the texinfo backend of help
- functionality which provides a restricted implementation of
- path syncronization to this specific area of documentation
- through the ,
- and options you can take as
- reference to implement it in other areas.
-
-
-
- The plan for a full implementation of path syncronization
- would be to create individual restricted implementations like
- the one in texinfo 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.
-
-
-
- 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.
-
-
-
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 @@
- Work Lines
+ Identifying Repository's Work Lines
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 @@
+
+
+ Preparing Your Workstation
+
+ &repo-ws-overview;
+ &repo-ws-install;
+ &repo-ws-config;
+
+
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 @@
+
+
+ Configuring Your Workstation
+
+
+ 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.
+
+
+
+
+ The Workplace
+
+
+ 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
+ useradd and passwd 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 root
+ superuser for doing so.
+
+
+
+
+ Do not use the root username for your
+ everyday's work inside your working copy of &TCAR;. This is
+ dangerous and might provoke unreversable damages on your
+ workstation.
+
+
+
+
+ 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;:
+
+
+
+
+ Case 1: Different home directories
+
+
+ Assuming you store your working copy under /home/john/artwork/ and I store
+ mine under /home/al/artwork/, 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.
+
+
+
+
+
+ Case 2: One unique home directory
+
+
+ Another case would be that you and I ourselves use one unique
+ home directory (e.g., /home/centos/artwork/) 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
+ centos 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.
+
+
+
+
+
+ Case 3: Different home directories through dynamic expansion
+
+
+ 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 $HOME 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).
+
+
+
+
+
+
+ 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.
+
+
+
+ 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.
+
+
+
+
+
+ The Environment Variables
+
+
+ Once you've created the centos 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., ~/.bash_profile) 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.
+
+
+
+
+ Default text editor
+
+
+ The default text editor information is controlled by the
+ EDITOR environment variable. The
+ centos-art.sh script uses the default text
+ editor to edit subversion pre-commit messages, translation
+ files, documentation files, script files, and similar
+ text-based files.
+
+
+
+ If EDITOR environment variable is not set,
+ centos-art.sh script uses /usr/bin/vim as default text
+ editor. Otherwise, the following values are recognized by
+ centos-art.sh script:
+
+
+
+
+ /usr/bin/vim
+
+
+
+
+
+ /usr/bin/emacs
+
+
+
+
+
+ /usr/bin/nano
+
+
+
+
+
+
+
+ If no one of these values is set in the EDITOR
+ environment variable, the centos-art.sh
+ script uses /usr/bin/vim text editor, the one
+ installed by default in &TCD;.
+
+
+
+
+
+ Default locale information
+
+
+ The default locale information is controlled by the
+ LANG environment variable. This variable is
+ initially set in the installation process of &TCD;,
+ specifically in the Language 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
+ system-config-language command.
+
+
+
+ The centos-art.sh script uses the
+ LANG 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;.
+
+
+
+
+
+ Default time zone representation
+
+
+ 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.
+
+
+ &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.
+
+
+ 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 TZ environment
+ variable in your personal profile to correct the time
+ information by yourself. The format of TZ
+ environment variable is described in tzset(3)
+ manual page.
+
+
+
+
+
+
+
+ The Administrative Tasks
+
+
+ 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.
+
+
+
+ To perform administrative tasks in your workstation, you need
+ to login as root or configure the
+ sudo program to temporarily granting the
+ permissions your regular user needs to perform the
+ administrative tasks. The configuration of
+ sudo program is at
+ /etc/sudoers file and you need to add the
+ centos user to the list of privileged
+ user as described in the section below:
+
+
+
+## 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
+
+
+
+ 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 prepare
+ functionality of the centos-art.sh script
+ in the sake of reducing work and standardize the procedure of
+ performing them. It is also worth to mention that, the
+ centos-art.sh script is available for you
+ to run, study, improve and share your changes as described in
+ .
+
+
+
+
+
+ The Working Copy
+
+
+ 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.
+
+
+
+ To download the working copy of &TCAR; you need to login as
+ your everyday's work user (i.e., the
+ centos 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:
+
+
+ svn co https://projects.centos.org/svn/artwork ~/
+
+
+ This command will create your working copy of &TCAR; in your
+ workstation, specifically in the /home/centos/artwork directory.
+
+
+
+ If the Subversion's client wasn't installed by default, you
+ need to install it using the following command:
+
+
+ sudo yum install subversion
+
+
+ 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).
+
+
+
+ In order to standardize all these preparation stuff, the
+ centos-art.sh script provides the
+ prepare functionality as described in
+ . Execute it right now,
+ to be sure your workstation and your working copy are both
+ ready to be used.
+
+
+
+
+
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 @@
+
+
+ Installing Your Workstation
+
+
+ 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.
+
+
+
+ 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.
+
+
+
+ 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;.
+
+
+
+ Assuming you downloaded the DVD ISO of &TCD;, you can burn it
+ using the K3B 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.
+
+
+
+ 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.
+
+
+
+
+ The Partition Information
+
+
+ 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.
+
+
+
+ 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
+ (/dev/sda) and the other one as secondary
+ (/dev/sdb) where the secondary is used
+ only to backup the information produced in the primary by mean
+ of backup scripts.
+
+
+ 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., /, /boot and swap partition) where
+ the working copy is placed in. The second hard drive is an
+ entire partition mounted in /mnt/backups automatically on
+ boot which only purpose is to duplicate the information
+ produced in the workplace.
+
+
+
+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
+
+
+
+ The detailed steps followed to prepare the partinioning layout
+ described above are described in the Deployment
+ Guide provided by
+ Deployment_Guide-en-US-5.2-11.el5.centos
+ package.
+
+
+
+
+
+
+ The Packages Selection
+
+
+ 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:
+
+
+
+
+ Desktop Environments
+
+
+
+ GNOME Desktop Environment
+
+
+
+
+ KDE (K Desktop Environment)
+
+
+
+
+
+
+ Applications
+
+
+
+ Authoring and Publishing
+
+
+
+
+ Editors
+
+
+
+
+ Graphical Internet
+
+
+
+
+ Graphics
+
+
+
+
+ Office/Productivity
+
+
+
+
+ Text-based Internet
+
+
+
+
+
+
+ Development
+
+
+
+ Development Libraries
+
+
+
+
+ Development Tools
+
+
+
+
+ GNOME Software Development
+
+
+
+
+ KDE Software Development
+
+
+
+
+
+
+
+ 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
+ inkscape 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 Repositories
+ page.
+
+
+
+
+
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 @@
+
+
+ Overview
+
+
+ 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.
+
+
+
+ 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.
+
+
+
+ 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.
+
+
+
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 @@
Synopsis
-
- centos-art help [OPTIONS] path/to/dir …
-
+ centos-art help [OPTIONS] path/to/dir ...
The path/to/dir 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 @@
The <function>prepare</function> functionality
- ...
+
+
+ Assuming this is the very first time you run the
+ centos-art.sh 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 centos-art.sh command-line
+ available in the execution path of your workstation, you need
+ to run it using its absolute path first:
+
+
+ ~/artwork/trunk/Scripts/centos-art.sh prepare [OPTIONS]
+
+
+ Later, once the centos-art.sh 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 centos-art command-line
+ interface directly, as the following example describes:
+
+
+ centos-art prepare [OPTIONS]
+
+
+ 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 ~/.gimp-2.2/brushes 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.
+