diff --git a/Manuals/Repository/Docbook/Commons.ent b/Manuals/Repository/Docbook/Commons.ent index 88dad24..3091319 100644 --- a/Manuals/Repository/Docbook/Commons.ent +++ b/Manuals/Repository/Docbook/Commons.ent @@ -20,7 +20,7 @@ <!ENTITY C "CentOS"> <!ENTITY TC "The &C;"> -<!ENTITY TCP "<ulink url='http://www.centos.org'>&TC; Project</ulink>"> +<!ENTITY TCP "<ulink type='http' url='http://www.centos.org'>&TC; Project</ulink>"> <!ENTITY TCC "&TC; Community"> <!ENTITY TCD "&TC; Distribution"> <!ENTITY TCA "&TC; Artwork"> @@ -31,13 +31,13 @@ <!ENTITY TCPCVIS "&TCP; &CVIS;"> <!ENTITY TCPMCVIS "&TCP; &MCVIS;"> -<!ENTITY TCAR "<ulink url='https://projects.centos.org/svn/artwork'>&TCA; Repository</ulink>"> -<!ENTITY TCAS "<ulink url='https://projects.centos.org/trac/artwork'>&TCA; SIG</ulink>"> +<!ENTITY TCAR "<ulink type='https' url='https://projects.centos.org/svn/artwork'>&TCA; Repository</ulink>"> +<!ENTITY TCAS "<ulink type='https' url='https://projects.centos.org/trac/artwork'>&TCA; SIG</ulink>"> <!ENTITY TCARUG "&TCAR; User's Guide"> <!ENTITY TCDRS "&TCD; Release Schema"> -<!ENTITY TCAML "<ulink url='http://lists.centos.org/mailman/centos-artwork'>&TCA; Mailing List</ulink>"> -<!ENTITY TCDML "<ulink url='http://lists.centos.org/mailman/centos-devel'>&TC; Developers Mailing List</ulink>"> +<!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 TCW "&TC; Web Environment"> <!ENTITY TCS "&TC; Showroom"> <!ENTITY TCB "&TC; Brand"> diff --git a/Manuals/Repository/Docbook/Introduction.docbook b/Manuals/Repository/Docbook/Introduction.docbook index cfc091d..d483c3b 100644 --- a/Manuals/Repository/Docbook/Introduction.docbook +++ b/Manuals/Repository/Docbook/Introduction.docbook @@ -9,11 +9,10 @@ </para> <para> - &TCARUG; describes how The CentOS Project corporate visual - identity is organized and produced inside &TCAR;. If you are - looking for a comprehensive, task-oriented guide for - understanding how &TCPCI; is produced, this is the manual for - you. + &TCARUG; describes how &TCPCVI; is organized and produced + inside &TCAR;. If you are looking for a comprehensive, + task-oriented guide for understanding how &TCPCI; is produced, + this is the manual for you. </para> <para> @@ -29,9 +28,6 @@ &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 6cf79cb..d730bd1 100644 --- a/Manuals/Repository/Docbook/Introduction.ent +++ b/Manuals/Repository/Docbook/Introduction.ent @@ -10,13 +10,17 @@ <!ENTITY intro-docconvs SYSTEM "Introduction/Docconvs.docbook"> -<!ENTITY intro-copying SYSTEM "Introduction/Copying.docbook"> -<!ENTITY intro-policy SYSTEM "Introduction/Policy.docbook"> -<!ENTITY intro-worklines SYSTEM "Introduction/Worklines.docbook"> -<!ENTITY intro-relbdirs SYSTEM "Introduction/Relbdirs.docbook"> -<!ENTITY intro-syncpaths SYSTEM "Introduction/Syncpaths.docbook"> -<!ENTITY intro-extending SYSTEM "Introduction/Extending.docbook"> -<!ENTITY intro-filenames SYSTEM "Introduction/Filenames.docbook"> -<!ENTITY intro-layout SYSTEM "Introduction/Layout.docbook"> +<!ENTITY intro-copying SYSTEM "Introduction/Copying.docbook"> +<!ENTITY intro-policy SYSTEM "Introduction/Policy.docbook"> +<!ENTITY intro-worklines SYSTEM "Introduction/Worklines.docbook"> +<!ENTITY intro-worklines-identity SYSTEM "Introduction/Worklines/identity.docbook"> +<!ENTITY intro-worklines-l10n SYSTEM "Introduction/Worklines/l10n.docbook"> +<!ENTITY intro-worklines-manuals SYSTEM "Introduction/Worklines/manuals.docbook"> +<!ENTITY intro-worklines-scripts SYSTEM "Introduction/Worklines/scripts.docbook"> +<!ENTITY intro-worklines-relbdirs SYSTEM "Introduction/Worklines/relbdirs.docbook"> +<!ENTITY intro-worklines-syncpaths SYSTEM "Introduction/Worklines/syncpaths.docbook"> +<!ENTITY intro-worklines-extending SYSTEM "Introduction/Worklines/extending.docbook"> +<!ENTITY intro-filenames SYSTEM "Introduction/Filenames.docbook"> +<!ENTITY intro-layout SYSTEM "Introduction/Layout.docbook"> <!ENTITY intro-feedback SYSTEM "Introduction/Feedback.docbook"> diff --git a/Manuals/Repository/Docbook/Introduction/Extending.docbook b/Manuals/Repository/Docbook/Introduction/Extending.docbook deleted file mode 100644 index e0bfa67..0000000 --- a/Manuals/Repository/Docbook/Introduction/Extending.docbook +++ /dev/null @@ -1,42 +0,0 @@ -<chapter id="intro-repoconvs-extending"> - - <title>Extending Repository Organization</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. Using this information and the one provided in <xref - linkend="intro-repoconvs-layout" />, it is possible for you to - find out good places for extending &TCAR;. - </para> - -</chapter> diff --git a/Manuals/Repository/Docbook/Introduction/Layout.docbook b/Manuals/Repository/Docbook/Introduction/Layout.docbook index 4b29108..048a0a6 100644 --- a/Manuals/Repository/Docbook/Introduction/Layout.docbook +++ b/Manuals/Repository/Docbook/Introduction/Layout.docbook @@ -46,7 +46,7 @@ <para> The second level of directories in the repository provides organization for each work line described in <xref - linkend="intro-repoconvs-worklines" />. + linkend="intro-worklines" />. </para> <para> diff --git a/Manuals/Repository/Docbook/Introduction/Relbdirs.docbook b/Manuals/Repository/Docbook/Introduction/Relbdirs.docbook deleted file mode 100644 index 48e2f81..0000000 --- a/Manuals/Repository/Docbook/Introduction/Relbdirs.docbook +++ /dev/null @@ -1,128 +0,0 @@ -<chapter id="intro-repoconvs-relbdirs"> - - <title>Relation Between Directories</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> - - <para> - To better understand what each directory inside the repository - means, read <xref linkend="intro-repoconvs-layout" />. - </para> - -</chapter> diff --git a/Manuals/Repository/Docbook/Introduction/Syncpaths.docbook b/Manuals/Repository/Docbook/Introduction/Syncpaths.docbook deleted file mode 100644 index 3d6245b..0000000 --- a/Manuals/Repository/Docbook/Introduction/Syncpaths.docbook +++ /dev/null @@ -1,93 +0,0 @@ -<chapter id="intro-repoconvs-syncpaths"> - - <title>Syncronizing Paths</title> - - <para> - 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 <emphasis>path syncronization</emphasis>. - </para> - - <para> - 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 - <command>centos-art.sh</command> script to know where to - retrive the information it needs to work with. Path - syncronization is the way we use to organize and extend the - information stored in the repository. - </para> - - <para> - Path syncronization 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. - </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 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. - </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 - 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> - -</chapter> diff --git a/Manuals/Repository/Docbook/Introduction/Worklines.docbook b/Manuals/Repository/Docbook/Introduction/Worklines.docbook index 14beb48..6f6987c 100644 --- a/Manuals/Repository/Docbook/Introduction/Worklines.docbook +++ b/Manuals/Repository/Docbook/Introduction/Worklines.docbook @@ -1,93 +1,24 @@ -<chapter id="intro-repoconvs-worklines"> +<chapter id="intro-worklines"> <title>Repository Work Lines</title> <para> 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;. + another based on the idea of doing one thing well. Later, the + results produced individually by each work line are combined + to achieve a higher purpose. Work lines, as conceived here, + provide the relayable output components the production cycle + inside &TCAR; needs to let everyone to work syncronized in a + descentralized environment. </para> - - <variablelist> - <varlistentry> - <term>Visual Identity (<filename class="directory">trunk/Identity</filename>)</term> - <listitem> - <para> - 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 - <function>render</function> functionality of - <command>centos-art.sh</command> script to combine both design - models and artistic motifs in order to produce the final - images required by each visual manifestaions. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Localization (<filename class="directory">trunk/L10n</filename>)</term> - <listitem> - <para> - 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 - <function>locale</function> functionality of the - <command>centos-art.sh</command> script which take care of - retriving translatable strings from source files and provide a - consistent localization interface based on the ideas behind - GNU <application>gettext</application> multi-lingual message - production. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Documentation (<filename class="directory">trunk/Manuals</filename>)</term> - <listitem> - <para> - 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 <function>help</function> functionality of - <command>centos-art.sh</command> script which provide an - consistent interface for building documentation through - different documentation backends (e.g., Texinfo, DocBook). - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Automation (<filename class="directory">trunk/Scripts</filename>)</term> - <listitem> - <para> - 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 <command>centos-art.sh</command> script and all - its functionalities (e.g., <function>render</function> for - rendition, <function>help</function> for documentation, - <function>locale</function> 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. - </para> - </listitem> - </varlistentry> - </variablelist> + &intro-worklines-identity; + &intro-worklines-l10n; + &intro-worklines-manuals; + &intro-worklines-scripts; + &intro-worklines-relbdirs; + &intro-worklines-syncpaths; + &intro-worklines-extending; + </chapter> diff --git a/Manuals/Repository/Docbook/Introduction/Worklines/extending.docbook b/Manuals/Repository/Docbook/Introduction/Worklines/extending.docbook new file mode 100644 index 0000000..5c9978a --- /dev/null +++ b/Manuals/Repository/Docbook/Introduction/Worklines/extending.docbook @@ -0,0 +1,42 @@ +<sect1 id="intro-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. Using this information and the one provided in <xref + linkend="intro-repoconvs-layout" />, it is possible for you to + find out good places for extending &TCAR;. + </para> + +</sect1> diff --git a/Manuals/Repository/Docbook/Introduction/Worklines/identity.docbook b/Manuals/Repository/Docbook/Introduction/Worklines/identity.docbook new file mode 100644 index 0000000..4b7626d --- /dev/null +++ b/Manuals/Repository/Docbook/Introduction/Worklines/identity.docbook @@ -0,0 +1,26 @@ +<sect1 id="intro-worklines-idenity"> + + <title>Visual Identity</title> + + <para> + 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 they look and + feel). + </para> + + <para> + Finally, graphic designers use the + <function>render</function> functionality of + <command>centos-art.sh</command> script to combine both design + models and artistic motifs in order to produce the final + images required by each visual manifestaions. + </para> + +</sect1> diff --git a/Manuals/Repository/Docbook/Introduction/Worklines/l10n.docbook b/Manuals/Repository/Docbook/Introduction/Worklines/l10n.docbook new file mode 100644 index 0000000..31f5ebc --- /dev/null +++ b/Manuals/Repository/Docbook/Introduction/Worklines/l10n.docbook @@ -0,0 +1,22 @@ +<sect1 id="intro-worklines-l10n"> + + <title>Localization</title> + + <para> + 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. + </para> + + <para> + The localization tasks are carried on by translators using the + <function>locale</function> functionality of the + <command>centos-art.sh</command> script which take care of + retriving translatable strings from source files and provide a + consistent localization interface based on GNU + <application>gettext</application> multi-lingual message + production tool set and <command>xml2po</command> command. + </para> + +</sect1> diff --git a/Manuals/Repository/Docbook/Introduction/Worklines/manuals.docbook b/Manuals/Repository/Docbook/Introduction/Worklines/manuals.docbook new file mode 100644 index 0000000..1718f28 --- /dev/null +++ b/Manuals/Repository/Docbook/Introduction/Worklines/manuals.docbook @@ -0,0 +1,20 @@ +<sect1 id="intro-worklines-manuals"> + + <title>Documentation</title> + + <para> + 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 through &TCARUG;. + </para> + + <para> + To write documentation, documentors use the + <function>help</function> functionality of + <command>centos-art.sh</command> script which provide an + consistent interface for building documentation through + different documentation backends (e.g., Texinfo and DocBook). + </para> + +</sect1> diff --git a/Manuals/Repository/Docbook/Introduction/Worklines/relbdirs.docbook b/Manuals/Repository/Docbook/Introduction/Worklines/relbdirs.docbook new file mode 100644 index 0000000..22bf7f8 --- /dev/null +++ b/Manuals/Repository/Docbook/Introduction/Worklines/relbdirs.docbook @@ -0,0 +1,128 @@ +<sect1 id="intro-worklines-relbdirs"> + + <title>Relation Between Directories</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> + + <para> + To better understand what each directory inside the repository + means, read <xref linkend="intro-repoconvs-layout" />. + </para> + +</sect1> diff --git a/Manuals/Repository/Docbook/Introduction/Worklines/scripts.docbook b/Manuals/Repository/Docbook/Introduction/Worklines/scripts.docbook new file mode 100644 index 0000000..0ceaa6b --- /dev/null +++ b/Manuals/Repository/Docbook/Introduction/Worklines/scripts.docbook @@ -0,0 +1,24 @@ +<sect1 id="intro-worklines-scripts"> + + <title>Automation</title> + + <para> + 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 + the <command>centos-art.sh</command> script and all + its functionalities (e.g., <function>render</function> for + rendition, <function>help</function> for documentation, + <function>locale</function> for localization, etc.) are + developed. + </para> + + <para> + 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. + </para> + +</sect1> diff --git a/Manuals/Repository/Docbook/Introduction/Worklines/syncpaths.docbook b/Manuals/Repository/Docbook/Introduction/Worklines/syncpaths.docbook new file mode 100644 index 0000000..a6e8219 --- /dev/null +++ b/Manuals/Repository/Docbook/Introduction/Worklines/syncpaths.docbook @@ -0,0 +1,96 @@ +<sect1 id="intro-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>