diff --git a/Manuals/Repository/Docbook/Introduction.docbook b/Manuals/Repository/Docbook/Introduction.docbook
index c83b0dc..cfc091d 100644
--- a/Manuals/Repository/Docbook/Introduction.docbook
+++ b/Manuals/Repository/Docbook/Introduction.docbook
@@ -26,6 +26,13 @@
&intro-history;
- &intro-repoconvs;
+ &intro-copying;
+ &intro-policy;
+ &intro-worklines;
+ &intro-relbdirs;
+ &intro-syncpaths;
+ &intro-extending;
+ &intro-filenames;
+ &intro-layout;
diff --git a/Manuals/Repository/Docbook/Introduction.ent b/Manuals/Repository/Docbook/Introduction.ent
index 10e9549..6cf79cb 100644
--- a/Manuals/Repository/Docbook/Introduction.ent
+++ b/Manuals/Repository/Docbook/Introduction.ent
@@ -10,14 +10,13 @@
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
diff --git a/Manuals/Repository/Docbook/Introduction/Copying.docbook b/Manuals/Repository/Docbook/Introduction/Copying.docbook
new file mode 100644
index 0000000..20cdc88
--- /dev/null
+++ b/Manuals/Repository/Docbook/Introduction/Copying.docbook
@@ -0,0 +1,72 @@
+
+
+ Repository Copying Conditions
+
+
+ ©RIGHT;
+
+
+
+ &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/Repository/Docbook/Introduction/Extending.docbook b/Manuals/Repository/Docbook/Introduction/Extending.docbook
new file mode 100644
index 0000000..e0bfa67
--- /dev/null
+++ b/Manuals/Repository/Docbook/Introduction/Extending.docbook
@@ -0,0 +1,42 @@
+
+
+ Extending Repository Organization
+
+
+ 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. Using this information and the one provided in , it is possible for you to
+ find out good places for extending &TCAR;.
+
+
+
diff --git a/Manuals/Repository/Docbook/Introduction/Filenames.docbook b/Manuals/Repository/Docbook/Introduction/Filenames.docbook
new file mode 100644
index 0000000..fccaea7
--- /dev/null
+++ b/Manuals/Repository/Docbook/Introduction/Filenames.docbook
@@ -0,0 +1,27 @@
+
+
+ Repository 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/Repository/Docbook/Introduction/Layout.docbook b/Manuals/Repository/Docbook/Introduction/Layout.docbook
new file mode 100644
index 0000000..4b29108
--- /dev/null
+++ b/Manuals/Repository/Docbook/Introduction/Layout.docbook
@@ -0,0 +1,60 @@
+
+
+ Repository Layout
+
+
+ &TCAR; is supported by Subversion, a
+ version control system which allows you to keep old versions
+ of files and directories (usually source code), keep a log of
+ who, when, and why changes occurred, etc., like CVS, RCS or
+ SCCS.
+
+
+
+ When using Subversion there is one source
+ repository and many working copies of
+ that source repository. The working copies are independent one
+ another, can be distributed all around the world and provide a
+ local place for designers, documentors, translators and
+ programmers to perform their work in a descentralized way.
+ The source repository, on the other hand, provides a central
+ place for all independent working copies to interchange data
+ and provides the information required to permit extracting
+ previous versions of files at any time.
+
+
+
+ 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. A complete reference for
+ each directory inside &TCAR; is available at .
+
+
+
diff --git a/Manuals/Repository/Docbook/Introduction/Policy.docbook b/Manuals/Repository/Docbook/Introduction/Policy.docbook
new file mode 100644
index 0000000..f2ee617
--- /dev/null
+++ b/Manuals/Repository/Docbook/Introduction/Policy.docbook
@@ -0,0 +1,66 @@
+
+
+ Repository Policy
+
+
+ &TCAR; is a collaborative tool that anyone can have access to.
+ However, changing that tool in any form is something that
+ should be requested in &TCDML;. Generally, people download
+ working copies of &TCAR; to study its organization, make local
+ changes, test the changes really work the way expected and
+ finally, request access to commit them up to &TCAR; for others
+ to benefit from them.
+
+
+
+ Once you've received access to commit your changes, there is
+ no need for you to request permission again to commit other
+ changes from your working copy to &TCAR; as long as you behave
+ as a good cooperating citizen.
+ Otherwise, your rights to commit changes might be temporarly
+ revoked or permanently banished.
+
+
+
+ As a good cooperating citizen one understand of a person who
+ respects the work already done by others and share ideas with
+ authors before changing relevant parts of their work,
+ specially in situations when the access required to realize
+ the changes has been granted already. Of course, there is a
+ time when conversation has taken place, the paths has been
+ traced and changing the work is so obvious that there is no
+ need for you to talk about it; that's because you already did,
+ you already built the trust to keep going. As complement, the
+ mailing list mentioned above is available for sharing ideas in
+ a way that good relationship between community citizens could
+ be constantly balanced.
+
+
+
+ The relationship between community citizens is monitored by
+ repository administrators. Repository administrators are
+ responsible of granting that everything goes the way it needs
+ to go in order for &TCAR; to accomplish its mission which is:
+ to provide a colaborative tool for &TCC; where &TCPCVI; could
+ be built and maintained by &TCC; itself.
+
+
+
+ The content produced inside &TCAR; is copyright of &TCAS; and
+ this is something you, as author, need to be aware of because
+ you are giving part of your creation's rights to someone else;
+ &TCAS; for this matter. In this case, your work is
+ distributed using &TCAS; as copyright holder not your name.
+ Because &TCAS; is the copyright holder, is the license chosen
+ by &TCAS; the one applied to your work, so it is the one you
+ need to agree with before making a creation inside &TCAR;.
+
+
+
+ We belive that working together is far better than working
+ alone; eventhough somtimes, working alone is the only possible
+ way of reaching the state of glory which is to work
+ syncronized all together in freedom.
+
+
+
diff --git a/Manuals/Repository/Docbook/Introduction/Relbdirs.docbook b/Manuals/Repository/Docbook/Introduction/Relbdirs.docbook
new file mode 100644
index 0000000..48e2f81
--- /dev/null
+++ b/Manuals/Repository/Docbook/Introduction/Relbdirs.docbook
@@ -0,0 +1,128 @@
+
+
+ Relation Between Directories
+
+
+ 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.
+
+
+
+ To better understand what each directory inside the repository
+ means, read .
+
+
+
diff --git a/Manuals/Repository/Docbook/Introduction/Repoconvs.docbook b/Manuals/Repository/Docbook/Introduction/Repoconvs.docbook
deleted file mode 100644
index 0e7873b..0000000
--- a/Manuals/Repository/Docbook/Introduction/Repoconvs.docbook
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
- Repository Convenctions
-
- &intro-repoconvs-copying;
- &intro-repoconvs-policy;
- &intro-repoconvs-worklines;
- &intro-repoconvs-relbdirs;
- &intro-repoconvs-syncpaths;
- &intro-repoconvs-extending;
- &intro-repoconvs-filenames;
- &intro-repoconvs-layout;
-
-
diff --git a/Manuals/Repository/Docbook/Introduction/Repoconvs/copying.docbook b/Manuals/Repository/Docbook/Introduction/Repoconvs/copying.docbook
deleted file mode 100644
index 1d4508f..0000000
--- a/Manuals/Repository/Docbook/Introduction/Repoconvs/copying.docbook
+++ /dev/null
@@ -1,72 +0,0 @@
-
-
- Copying Conditions
-
-
- ©RIGHT;
-
-
-
- &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/Repository/Docbook/Introduction/Repoconvs/extending.docbook b/Manuals/Repository/Docbook/Introduction/Repoconvs/extending.docbook
deleted file mode 100644
index d974d41..0000000
--- a/Manuals/Repository/Docbook/Introduction/Repoconvs/extending.docbook
+++ /dev/null
@@ -1,42 +0,0 @@
-
-
- Extending Repository Organization
-
-
- 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. Using this information and the one provided in , it is possible for you to
- find out good places for extending &TCAR;.
-
-
-
diff --git a/Manuals/Repository/Docbook/Introduction/Repoconvs/filenames.docbook b/Manuals/Repository/Docbook/Introduction/Repoconvs/filenames.docbook
deleted file mode 100644
index 777bb74..0000000
--- a/Manuals/Repository/Docbook/Introduction/Repoconvs/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/Repository/Docbook/Introduction/Repoconvs/layout.docbook b/Manuals/Repository/Docbook/Introduction/Repoconvs/layout.docbook
deleted file mode 100644
index 6634f7c..0000000
--- a/Manuals/Repository/Docbook/Introduction/Repoconvs/layout.docbook
+++ /dev/null
@@ -1,60 +0,0 @@
-
-
- The Repository Layout
-
-
- &TCAR; is supported by Subversion, a
- version control system which allows you to keep old versions
- of files and directories (usually source code), keep a log of
- who, when, and why changes occurred, etc., like CVS, RCS or
- SCCS.
-
-
-
- When using Subversion there is one source
- repository and many working copies of
- that source repository. The working copies are independent one
- another, can be distributed all around the world and provide a
- local place for designers, documentors, translators and
- programmers to perform their work in a descentralized way.
- The source repository, on the other hand, provides a central
- place for all independent working copies to interchange data
- and provides the information required to permit extracting
- previous versions of files at any time.
-
-
-
- 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. A complete reference for
- each directory inside &TCAR; is available at .
-
-
-
diff --git a/Manuals/Repository/Docbook/Introduction/Repoconvs/policy.docbook b/Manuals/Repository/Docbook/Introduction/Repoconvs/policy.docbook
deleted file mode 100644
index eafdfa6..0000000
--- a/Manuals/Repository/Docbook/Introduction/Repoconvs/policy.docbook
+++ /dev/null
@@ -1,66 +0,0 @@
-
-
- Policy
-
-
- &TCAR; is a collaborative tool that anyone can have access to.
- However, changing that tool in any form is something that
- should be requested in &TCDML;. Generally, people download
- working copies of &TCAR; to study its organization, make local
- changes, test the changes really work the way expected and
- finally, request access to commit them up to &TCAR; for others
- to benefit from them.
-
-
-
- Once you've received access to commit your changes, there is
- no need for you to request permission again to commit other
- changes from your working copy to &TCAR; as long as you behave
- as a good cooperating citizen.
- Otherwise, your rights to commit changes might be temporarly
- revoked or permanently banished.
-
-
-
- As a good cooperating citizen one understand of a person who
- respects the work already done by others and share ideas with
- authors before changing relevant parts of their work,
- specially in situations when the access required to realize
- the changes has been granted already. Of course, there is a
- time when conversation has taken place, the paths has been
- traced and changing the work is so obvious that there is no
- need for you to talk about it; that's because you already did,
- you already built the trust to keep going. As complement, the
- mailing list mentioned above is available for sharing ideas in
- a way that good relationship between community citizens could
- be constantly balanced.
-
-
-
- The relationship between community citizens is monitored by
- repository administrators. Repository administrators are
- responsible of granting that everything goes the way it needs
- to go in order for &TCAR; to accomplish its mission which is:
- to provide a colaborative tool for &TCC; where &TCPCVI; could
- be built and maintained by &TCC; itself.
-
-
-
- The content produced inside &TCAR; is copyright of &TCAS; and
- this is something you, as author, need to be aware of because
- you are giving part of your creation's rights to someone else;
- &TCAS; for this matter. In this case, your work is
- distributed using &TCAS; as copyright holder not your name.
- Because &TCAS; is the copyright holder, is the license chosen
- by &TCAS; the one applied to your work, so it is the one you
- need to agree with before making a creation inside &TCAR;.
-
-
-
- We belive that working together is far better than working
- alone; eventhough somtimes, working alone is the only possible
- way of reaching the state of glory which is to work
- syncronized all together in freedom.
-
-
-
diff --git a/Manuals/Repository/Docbook/Introduction/Repoconvs/relbdirs.docbook b/Manuals/Repository/Docbook/Introduction/Repoconvs/relbdirs.docbook
deleted file mode 100644
index fda4b5f..0000000
--- a/Manuals/Repository/Docbook/Introduction/Repoconvs/relbdirs.docbook
+++ /dev/null
@@ -1,128 +0,0 @@
-
-
- Relation Between Directories
-
-
- 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.
-
-
-
- To better understand what each directory inside the repository
- means, read .
-
-
-
diff --git a/Manuals/Repository/Docbook/Introduction/Repoconvs/syncpaths.docbook b/Manuals/Repository/Docbook/Introduction/Repoconvs/syncpaths.docbook
deleted file mode 100644
index a651c66..0000000
--- a/Manuals/Repository/Docbook/Introduction/Repoconvs/syncpaths.docbook
+++ /dev/null
@@ -1,93 +0,0 @@
-
-
- Syncronizing Paths
-
-
- Once both master and auxiliar paths have been set in the
- repository, they shouldn't be changed. However, assuming you
- need to change them, it is required that you also change the
- relation between them, in order for both master and auxiliar
- paths to retain their relation one another. This process of
- keeping relation between master and auxiliar paths updated is
- known as path syncronization.
-
-
-
- Path syncronization is required for automation scripts to know
- where to store final output, where to retrive translation, and
- any information that might be desired. If the relation between
- master paths and auxiliar paths is lost, there is no way for
- centos-art.sh script to know where to
- retrive the information it needs to work with. Path
- syncronization is the way we use to organize and extend the
- information stored in the repository.
-
-
-
- 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 the 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 is performed, we avoid
- making replacements inside files first and file movements
- later. This would require two commit actions: one for the
- files' internal changes and another for the file movement
- itself. Otherwise, we prefer to perform file movements first
- and file internal replacements later. This way it is possible
- to commit both changes as if they were just one.
-
-
-
-
- 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
- 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/Repository/Docbook/Introduction/Repoconvs/worklines.docbook b/Manuals/Repository/Docbook/Introduction/Repoconvs/worklines.docbook
deleted file mode 100644
index b04524c..0000000
--- a/Manuals/Repository/Docbook/Introduction/Repoconvs/worklines.docbook
+++ /dev/null
@@ -1,93 +0,0 @@
-
-
- Work Lines
-
-
- To organize content production inside &TCAR;, production has
- been divided into individual work lines that relate one
- another. The is based on the idea of doing one thing well and
- later combine the result of each individual part to achieve a
- higher purpose. Work lines, as conceived here, provide
- relayable output components that combine one another to close
- the production cycle inside &TCAR;.
-
-
-
-
- Visual Identity (trunk/Identity)
-
-
- In the production cycle, the first step takes place through
- graphic design. It is focused on preparing design models for
- all the visual manifestation &TCP; is made of. Here, graphic
- designers describe the visual characteristics of each visual
- manifestation (e.g., image dimensions, position of text in the
- visible area, translation markers, etc.). Later, once design
- models have been defined, graphic designers take care of
- artistic motifs to define the visual style of those design
- models already created (e.g., how the look and feel).
- Furthermore, graphic designers use the
- render functionality of
- centos-art.sh script to combine both design
- models and artistic motifs in order to produce the final
- images required by each visual manifestaions.
-
-
-
-
-
- Localization (trunk/L10n)
-
-
- The second step in the production cycle is to localize
- source files (e.g., SVG, DocBook, Shell scripts). This step
- makes possible to produce localized images, localized
- documentation and localized automation scripts. The
- localization tasks are carried on by translators using the
- locale functionality of the
- centos-art.sh script which take care of
- retriving translatable strings from source files and provide a
- consistent localization interface based on the ideas behind
- GNU gettext multi-lingual message
- production.
-
-
-
-
-
- Documentation (trunk/Manuals)
-
-
- The third step in the production cycle is to document &TCAR;,
- what it is and how to use it. This step provides the
- conceptual ideas used as base to edificate &TCPCVI; and is
- implemented by mean of &TCARUG;. To write documentation,
- documentors use the help functionality of
- centos-art.sh script which provide an
- consistent interface for building documentation through
- different documentation backends (e.g., Texinfo, DocBook).
-
-
-
-
-
- Automation (trunk/Scripts)
-
-
- The fourth step in the production cycle is to automate
- frequent tasks inside &TCAR;. This step closes the production
- cycle and provides the production standards needed by all
- different work lines to coexist together. Here is where we
- develop the centos-art.sh script and all
- its functionalities (e.g., render for
- rendition, help for documentation,
- locale for localization, etc.). At this
- point it should be obvious, but we consider worth to remember
- that: there is no need to type several tasks, time after time,
- if they can be programmed into just one executable script.
-
-
-
-
-
-
diff --git a/Manuals/Repository/Docbook/Introduction/Syncpaths.docbook b/Manuals/Repository/Docbook/Introduction/Syncpaths.docbook
new file mode 100644
index 0000000..3d6245b
--- /dev/null
+++ b/Manuals/Repository/Docbook/Introduction/Syncpaths.docbook
@@ -0,0 +1,93 @@
+
+
+ Syncronizing Paths
+
+
+ Once both master and auxiliar paths have been set in the
+ repository, they shouldn't be changed. However, assuming you
+ need to change them, it is required that you also change the
+ relation between them, in order for both master and auxiliar
+ paths to retain their relation one another. This process of
+ keeping relation between master and auxiliar paths updated is
+ known as path syncronization.
+
+
+
+ Path syncronization is required for automation scripts to know
+ where to store final output, where to retrive translation, and
+ any information that might be desired. If the relation between
+ master paths and auxiliar paths is lost, there is no way for
+ centos-art.sh script to know where to
+ retrive the information it needs to work with. Path
+ syncronization is the way we use to organize and extend the
+ information stored in the repository.
+
+
+
+ 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 the 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 is performed, we avoid
+ making replacements inside files first and file movements
+ later. This would require two commit actions: one for the
+ files' internal changes and another for the file movement
+ itself. Otherwise, we prefer to perform file movements first
+ and file internal replacements later. This way it is possible
+ to commit both changes as if they were just one.
+
+
+
+
+ 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
+ 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/Repository/Docbook/Introduction/Worklines.docbook b/Manuals/Repository/Docbook/Introduction/Worklines.docbook
new file mode 100644
index 0000000..14beb48
--- /dev/null
+++ b/Manuals/Repository/Docbook/Introduction/Worklines.docbook
@@ -0,0 +1,93 @@
+
+
+ Repository Work Lines
+
+
+ To organize content production inside &TCAR;, production has
+ been divided into individual work lines that relate one
+ another. The is based on the idea of doing one thing well and
+ later combine the result of each individual part to achieve a
+ higher purpose. Work lines, as conceived here, provide
+ relayable output components that combine one another to close
+ the production cycle inside &TCAR;.
+
+
+
+
+ Visual Identity (trunk/Identity)
+
+
+ In the production cycle, the first step takes place through
+ graphic design. It is focused on preparing design models for
+ all the visual manifestation &TCP; is made of. Here, graphic
+ designers describe the visual characteristics of each visual
+ manifestation (e.g., image dimensions, position of text in the
+ visible area, translation markers, etc.). Later, once design
+ models have been defined, graphic designers take care of
+ artistic motifs to define the visual style of those design
+ models already created (e.g., how the look and feel).
+ Furthermore, graphic designers use the
+ render functionality of
+ centos-art.sh script to combine both design
+ models and artistic motifs in order to produce the final
+ images required by each visual manifestaions.
+
+
+
+
+
+ Localization (trunk/L10n)
+
+
+ The second step in the production cycle is to localize
+ source files (e.g., SVG, DocBook, Shell scripts). This step
+ makes possible to produce localized images, localized
+ documentation and localized automation scripts. The
+ localization tasks are carried on by translators using the
+ locale functionality of the
+ centos-art.sh script which take care of
+ retriving translatable strings from source files and provide a
+ consistent localization interface based on the ideas behind
+ GNU gettext multi-lingual message
+ production.
+
+
+
+
+
+ Documentation (trunk/Manuals)
+
+
+ The third step in the production cycle is to document &TCAR;,
+ what it is and how to use it. This step provides the
+ conceptual ideas used as base to edificate &TCPCVI; and is
+ implemented by mean of &TCARUG;. To write documentation,
+ documentors use the help functionality of
+ centos-art.sh script which provide an
+ consistent interface for building documentation through
+ different documentation backends (e.g., Texinfo, DocBook).
+
+
+
+
+
+ Automation (trunk/Scripts)
+
+
+ The fourth step in the production cycle is to automate
+ frequent tasks inside &TCAR;. This step closes the production
+ cycle and provides the production standards needed by all
+ different work lines to coexist together. Here is where we
+ develop the centos-art.sh script and all
+ its functionalities (e.g., render for
+ rendition, help for documentation,
+ locale for localization, etc.). At this
+ point it should be obvious, but we consider worth to remember
+ that: there is no need to type several tasks, time after time,
+ if they can be programmed into just one executable script.
+
+
+
+
+
+