diff --git a/Manuals/Repository/Docbook/Introduction.docbook b/Manuals/Repository/Docbook/Introduction.docbook deleted file mode 100644 index 03f3458..0000000 --- a/Manuals/Repository/Docbook/Introduction.docbook +++ /dev/null @@ -1,11 +0,0 @@ - - - Repository - - &repo-history; - &repo-copying; - &repo-usage; - &repo-worklines; - &repo-layout; - - diff --git a/Manuals/Repository/Docbook/Introduction.ent b/Manuals/Repository/Docbook/Introduction.ent deleted file mode 100644 index 9f38ae1..0000000 --- a/Manuals/Repository/Docbook/Introduction.ent +++ /dev/null @@ -1,28 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/Manuals/Repository/Docbook/Introduction/Copying.docbook b/Manuals/Repository/Docbook/Introduction/Copying.docbook deleted file mode 100644 index 7021d72..0000000 --- a/Manuals/Repository/Docbook/Introduction/Copying.docbook +++ /dev/null @@ -1,72 +0,0 @@ - - - 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/History.docbook b/Manuals/Repository/Docbook/Introduction/History.docbook deleted file mode 100644 index 7738cef..0000000 --- a/Manuals/Repository/Docbook/Introduction/History.docbook +++ /dev/null @@ -1,41 +0,0 @@ - - - Repository History - - - The CentOS Artwork Repository started at The CentOS Developers - Mailing List around 2008, on a discussion about how to - automate slide images used by Anaconda. In such discussion, - Ralph Angenendt rose up his hand to ask —Do you have - something to show?—. - - - - To answer the question, Alain Reguera Delgado suggested a bash - script which combined SVG and SED files in order to produce - PNG images in different languages —in conjunction with - the proposition of creating a Subversion repository where - translations and image production could be distributed inside - &TCC;—. - - - - Karanbirn Sighn considered the idea intresting and provided - the infrastructure necessary to support the effort. This way, - &TCAS; and &TCAR; were officially created and world wide - available. - - - - Once &TCAR; was available, Alain Reguera Delgado uploaded the - bash script Anaconda slides; Ralph Angenendt documented it - very well; and people started to download working copies of - the repository to produce slide images in their own languages. - - - &repo-history-2009; - &repo-history-2010; - &repo-history-2011; - - diff --git a/Manuals/Repository/Docbook/Introduction/History/2009.docbook b/Manuals/Repository/Docbook/Introduction/History/2009.docbook deleted file mode 100644 index 5e10ea5..0000000 --- a/Manuals/Repository/Docbook/Introduction/History/2009.docbook +++ /dev/null @@ -1,55 +0,0 @@ - - - 2009's - - - Around 2009, the rendition script was at a very rustic state - where only slide images could be produced, so it was - redesigned to extend the image production to other areas, - different from slide images. In this configuration, one SVG - file was used as input to produce a translated instance of it - which, in turn, was used to produce one translated PNG image - as output. The SVG translated instance was created through SED - replacement commands. The translated PNG image was created - from the SVG translated instance using Inkscape command-line - interface. - - - - The repository directory structure was prepared to receive the - rendition script using design templates and translation files - in the same location. There was one directory structure for - each artwork that needed to be produced. In this - configuration, if you would want to produce the same artwork - with a different visual style or structure, it was needed to - create a new directory structure for it because both the image - structure and the image visual style were together in the - design template. - - - - The rendition script was moved to a common place and linked - from different directory structures. There was no need to have - the same code in different directory structures if it could be - in just one place and then be linked from different locations. - - - - Corporate identity concepts began to be considered. As - referece, it was used the book "Corporate Identity" by Wally - Olins (1989) and Wikipedia - related links. This way, the rendition script main's goal - becomes to: automate the production process of a - monolithic corporate visual identity structure, based on the - mission and the release schema of The CentOS - Project. - - - - The repository directory structures began to be documented by - mean of flat text files. Later, documentation in flat text - files was moved onto LaTeX format and this way &TCARUG; was - initiated. - - diff --git a/Manuals/Repository/Docbook/Introduction/History/2010.docbook b/Manuals/Repository/Docbook/Introduction/History/2010.docbook deleted file mode 100644 index 6949b7e..0000000 --- a/Manuals/Repository/Docbook/Introduction/History/2010.docbook +++ /dev/null @@ -1,79 +0,0 @@ - - - 2010's - - - Around 2010, the rendition script changed its name from - render.sh to - centos-art.sh and became a collection of - functionalities where rendition was just one among others - (e.g., documentation and localization). - - - - The centos-art.sh was initially conceived - to automate frequent tasks inside the repository based in the - idea of Unix toolbox: to create small and specialized tools - that do one thing well. This way, functionalities inside - centos-art.sh began to be identified and - separated one another. For example, when images were rendered, - there was no need to load functionalities related to - documentation manual. This layout moved us onto common - functionalities and specific - functionalities inside - centos-art.sh script. Common - functionalities are loaded when - centos-art.sh script is initiated and are - available to specific functionalities. - - - - Suddenly, no need was found to keep all the links spreaded - around the repository in order to execute the - centos-art.sh script from different - locations. The centos-art command-line interface was used - instead. The centos-art command-line interface is a symbolic - link stored inside the ~/bin directory that point to - centos-art.sh script. As default - configuration, inside The CentOS Distribution, the path to - ~/bin is included in - the search path for commands (see PATH - environment variable). This way, using the centos-art - command-line interface, it is possible for us to execute the - centos-art.sh script from virtually - anywhere inside the workstation, just as we frequently do with - regular commands. - - - - Start using GNU getopt as default option parser inside the - centos-art.sh script. - - - - The repository directory structure was updated to improve the - implementation of corporate visual identity concepts. - Specially in the area related to themes. Having both structure - and style in the same file introduced content duplication when - producing art works. Because of this reason, they were - divided out to separate directory structures: the design - models and artistic motifs directory structures. From this - point on, the centos-art.sh is able to - produce themes as result of arbitrary combinations between - design models (structures) and artistic motifs (visual - styles). - - - - In the documentation area, the documents in LaTeX format were - migrated to Texinfo format. In this configuration, each - directory structure in the repository has a documentation - entry associated in a Texinfo structure which can be read, - edited and administered (e.g., renamed, deleted and copied) - interactively through centos-art.sh script. - Additionally, the texi2html program was used to produced - customized XHTML output in conjunction with CSS from &TCW;. - - - diff --git a/Manuals/Repository/Docbook/Introduction/History/2011.docbook b/Manuals/Repository/Docbook/Introduction/History/2011.docbook deleted file mode 100644 index 867d75e..0000000 --- a/Manuals/Repository/Docbook/Introduction/History/2011.docbook +++ /dev/null @@ -1,57 +0,0 @@ - - - 2011's - - - Around 2011, the centos-art.sh script was - redesigned to start translating XML-based files (e.g., SVG and - Docbook files) through xml2po program and - shell scripts (e.g., Bash scripts) through GNU gettext tools. - This configuration provided a stronger localization interface - for graphic designers, translators and programmers. The SED - replacement files are no longer used to handle localization. - - - - The render, help and - locale functionalities were consolidated - as the most frequent tasks performed inside the repository. - Additionally, the prepare and tuneup functionalities are also - maintained as useful tasks. - - - - In the documentation area, support for producing localized - transformations of DocBook XML DTD instances was added through - the render and locale functionalities. - The render functionality uses the - xsltproc command-line XSLT parser in - conjunction with the styles provided by the - docbook-style-xsl package, both of them - included inside The CentOS Distribution. The locale - functionality creates the localized portable object - (PO) the render - functionality needs to produce localized transformations of - DocBook XML DTD instances. - - - - To build DocBook documentation, it was considered the idea of - using concepts behind repository directory structure as base, - not the opposite (as I've been doing with Texinfo backend, so - far). - - - - Producing documentation through DocBook XML as default - documentation backend consolidates render - and locale even more. In this - configuration, once the DocBook files are written, you use - locale functionality to localize the - DocBook files in your prefered language and later, using - render functionality, you produce the - XTHML and PDF outputs as specified in a XSLT or DSL - customization layer. - - - diff --git a/Manuals/Repository/Docbook/Introduction/Layout.docbook b/Manuals/Repository/Docbook/Introduction/Layout.docbook deleted file mode 100644 index 46fc98b..0000000 --- a/Manuals/Repository/Docbook/Introduction/Layout.docbook +++ /dev/null @@ -1,63 +0,0 @@ - - - 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. - - - &repo-layout-filenames; - &repo-layout-relbdirs; - &repo-layout-syncpaths; - &repo-layout-extending; - - diff --git a/Manuals/Repository/Docbook/Introduction/Layout/extending.docbook b/Manuals/Repository/Docbook/Introduction/Layout/extending.docbook deleted file mode 100644 index d99c721..0000000 --- a/Manuals/Repository/Docbook/Introduction/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/Repository/Docbook/Introduction/Layout/filenames.docbook b/Manuals/Repository/Docbook/Introduction/Layout/filenames.docbook deleted file mode 100644 index 6941b4e..0000000 --- a/Manuals/Repository/Docbook/Introduction/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/Repository/Docbook/Introduction/Layout/relbdirs.docbook b/Manuals/Repository/Docbook/Introduction/Layout/relbdirs.docbook deleted file mode 100644 index 967bb8e..0000000 --- a/Manuals/Repository/Docbook/Introduction/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/Repository/Docbook/Introduction/Layout/syncpaths.docbook b/Manuals/Repository/Docbook/Introduction/Layout/syncpaths.docbook deleted file mode 100644 index 7b4ec2d..0000000 --- a/Manuals/Repository/Docbook/Introduction/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/Repository/Docbook/Introduction/Usage.docbook b/Manuals/Repository/Docbook/Introduction/Usage.docbook deleted file mode 100644 index b989fc4..0000000 --- a/Manuals/Repository/Docbook/Introduction/Usage.docbook +++ /dev/null @@ -1,66 +0,0 @@ - - - Repository Usage Conditions - - - &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 layout, make local - changes, test the changes really work the way expected and - finally, request access to publish them up. - - - - Once you've received access to publish your changes and as - long as you behave as a good cooperating - citizen, there is no need for you to request - permission to publish new changes. - - - - 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. Repository - administrators have the reposability of creating new user's - account, setting permissions and revoking publishing rights to - ill-willed users, as well. - - - - 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/Worklines.docbook b/Manuals/Repository/Docbook/Introduction/Worklines.docbook deleted file mode 100644 index e07819f..0000000 --- a/Manuals/Repository/Docbook/Introduction/Worklines.docbook +++ /dev/null @@ -1,21 +0,0 @@ - - - Repository Work Lines - - - To organize content production inside &TCAR;, production has - been divided into individual work lines that relate one - 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. - - - &repo-worklines-identity; - &repo-worklines-l10n; - &repo-worklines-manuals; - &repo-worklines-scripts; - - diff --git a/Manuals/Repository/Docbook/Introduction/Worklines/identity.docbook b/Manuals/Repository/Docbook/Introduction/Worklines/identity.docbook deleted file mode 100644 index 78205e7..0000000 --- a/Manuals/Repository/Docbook/Introduction/Worklines/identity.docbook +++ /dev/null @@ -1,26 +0,0 @@ - - - Visual 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 they look and - feel). - - - - Finally, 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. - - - diff --git a/Manuals/Repository/Docbook/Introduction/Worklines/l10n.docbook b/Manuals/Repository/Docbook/Introduction/Worklines/l10n.docbook deleted file mode 100644 index 8134155..0000000 --- a/Manuals/Repository/Docbook/Introduction/Worklines/l10n.docbook +++ /dev/null @@ -1,22 +0,0 @@ - - - Localization - - - 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 GNU - gettext multi-lingual message - production tool set and xml2po command. - - - diff --git a/Manuals/Repository/Docbook/Introduction/Worklines/manuals.docbook b/Manuals/Repository/Docbook/Introduction/Worklines/manuals.docbook deleted file mode 100644 index ef40f87..0000000 --- a/Manuals/Repository/Docbook/Introduction/Worklines/manuals.docbook +++ /dev/null @@ -1,20 +0,0 @@ - - - Documentation - - - 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;. - - - - 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 and DocBook). - - - diff --git a/Manuals/Repository/Docbook/Introduction/Worklines/scripts.docbook b/Manuals/Repository/Docbook/Introduction/Worklines/scripts.docbook deleted file mode 100644 index 53780f9..0000000 --- a/Manuals/Repository/Docbook/Introduction/Worklines/scripts.docbook +++ /dev/null @@ -1,24 +0,0 @@ - - - Automation - - - 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 centos-art.sh script and all - its functionalities (e.g., render for - rendition, help for documentation, - locale for localization, etc.) are - developed. - - - - 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/Repository.docbook b/Manuals/Repository/Docbook/Repository.docbook new file mode 100644 index 0000000..03f3458 --- /dev/null +++ b/Manuals/Repository/Docbook/Repository.docbook @@ -0,0 +1,11 @@ + + + Repository + + &repo-history; + &repo-copying; + &repo-usage; + &repo-worklines; + &repo-layout; + + diff --git a/Manuals/Repository/Docbook/Repository.ent b/Manuals/Repository/Docbook/Repository.ent new file mode 100644 index 0000000..025a53c --- /dev/null +++ b/Manuals/Repository/Docbook/Repository.ent @@ -0,0 +1,28 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/Manuals/Repository/Docbook/Repository/Copying.docbook b/Manuals/Repository/Docbook/Repository/Copying.docbook new file mode 100644 index 0000000..7021d72 --- /dev/null +++ b/Manuals/Repository/Docbook/Repository/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/Repository/History.docbook b/Manuals/Repository/Docbook/Repository/History.docbook new file mode 100644 index 0000000..7738cef --- /dev/null +++ b/Manuals/Repository/Docbook/Repository/History.docbook @@ -0,0 +1,41 @@ + + + Repository History + + + The CentOS Artwork Repository started at The CentOS Developers + Mailing List around 2008, on a discussion about how to + automate slide images used by Anaconda. In such discussion, + Ralph Angenendt rose up his hand to ask —Do you have + something to show?—. + + + + To answer the question, Alain Reguera Delgado suggested a bash + script which combined SVG and SED files in order to produce + PNG images in different languages —in conjunction with + the proposition of creating a Subversion repository where + translations and image production could be distributed inside + &TCC;—. + + + + Karanbirn Sighn considered the idea intresting and provided + the infrastructure necessary to support the effort. This way, + &TCAS; and &TCAR; were officially created and world wide + available. + + + + Once &TCAR; was available, Alain Reguera Delgado uploaded the + bash script Anaconda slides; Ralph Angenendt documented it + very well; and people started to download working copies of + the repository to produce slide images in their own languages. + + + &repo-history-2009; + &repo-history-2010; + &repo-history-2011; + + diff --git a/Manuals/Repository/Docbook/Repository/History/2009.docbook b/Manuals/Repository/Docbook/Repository/History/2009.docbook new file mode 100644 index 0000000..5e10ea5 --- /dev/null +++ b/Manuals/Repository/Docbook/Repository/History/2009.docbook @@ -0,0 +1,55 @@ + + + 2009's + + + Around 2009, the rendition script was at a very rustic state + where only slide images could be produced, so it was + redesigned to extend the image production to other areas, + different from slide images. In this configuration, one SVG + file was used as input to produce a translated instance of it + which, in turn, was used to produce one translated PNG image + as output. The SVG translated instance was created through SED + replacement commands. The translated PNG image was created + from the SVG translated instance using Inkscape command-line + interface. + + + + The repository directory structure was prepared to receive the + rendition script using design templates and translation files + in the same location. There was one directory structure for + each artwork that needed to be produced. In this + configuration, if you would want to produce the same artwork + with a different visual style or structure, it was needed to + create a new directory structure for it because both the image + structure and the image visual style were together in the + design template. + + + + The rendition script was moved to a common place and linked + from different directory structures. There was no need to have + the same code in different directory structures if it could be + in just one place and then be linked from different locations. + + + + Corporate identity concepts began to be considered. As + referece, it was used the book "Corporate Identity" by Wally + Olins (1989) and Wikipedia + related links. This way, the rendition script main's goal + becomes to: automate the production process of a + monolithic corporate visual identity structure, based on the + mission and the release schema of The CentOS + Project. + + + + The repository directory structures began to be documented by + mean of flat text files. Later, documentation in flat text + files was moved onto LaTeX format and this way &TCARUG; was + initiated. + + diff --git a/Manuals/Repository/Docbook/Repository/History/2010.docbook b/Manuals/Repository/Docbook/Repository/History/2010.docbook new file mode 100644 index 0000000..6949b7e --- /dev/null +++ b/Manuals/Repository/Docbook/Repository/History/2010.docbook @@ -0,0 +1,79 @@ + + + 2010's + + + Around 2010, the rendition script changed its name from + render.sh to + centos-art.sh and became a collection of + functionalities where rendition was just one among others + (e.g., documentation and localization). + + + + The centos-art.sh was initially conceived + to automate frequent tasks inside the repository based in the + idea of Unix toolbox: to create small and specialized tools + that do one thing well. This way, functionalities inside + centos-art.sh began to be identified and + separated one another. For example, when images were rendered, + there was no need to load functionalities related to + documentation manual. This layout moved us onto common + functionalities and specific + functionalities inside + centos-art.sh script. Common + functionalities are loaded when + centos-art.sh script is initiated and are + available to specific functionalities. + + + + Suddenly, no need was found to keep all the links spreaded + around the repository in order to execute the + centos-art.sh script from different + locations. The centos-art command-line interface was used + instead. The centos-art command-line interface is a symbolic + link stored inside the ~/bin directory that point to + centos-art.sh script. As default + configuration, inside The CentOS Distribution, the path to + ~/bin is included in + the search path for commands (see PATH + environment variable). This way, using the centos-art + command-line interface, it is possible for us to execute the + centos-art.sh script from virtually + anywhere inside the workstation, just as we frequently do with + regular commands. + + + + Start using GNU getopt as default option parser inside the + centos-art.sh script. + + + + The repository directory structure was updated to improve the + implementation of corporate visual identity concepts. + Specially in the area related to themes. Having both structure + and style in the same file introduced content duplication when + producing art works. Because of this reason, they were + divided out to separate directory structures: the design + models and artistic motifs directory structures. From this + point on, the centos-art.sh is able to + produce themes as result of arbitrary combinations between + design models (structures) and artistic motifs (visual + styles). + + + + In the documentation area, the documents in LaTeX format were + migrated to Texinfo format. In this configuration, each + directory structure in the repository has a documentation + entry associated in a Texinfo structure which can be read, + edited and administered (e.g., renamed, deleted and copied) + interactively through centos-art.sh script. + Additionally, the texi2html program was used to produced + customized XHTML output in conjunction with CSS from &TCW;. + + + diff --git a/Manuals/Repository/Docbook/Repository/History/2011.docbook b/Manuals/Repository/Docbook/Repository/History/2011.docbook new file mode 100644 index 0000000..867d75e --- /dev/null +++ b/Manuals/Repository/Docbook/Repository/History/2011.docbook @@ -0,0 +1,57 @@ + + + 2011's + + + Around 2011, the centos-art.sh script was + redesigned to start translating XML-based files (e.g., SVG and + Docbook files) through xml2po program and + shell scripts (e.g., Bash scripts) through GNU gettext tools. + This configuration provided a stronger localization interface + for graphic designers, translators and programmers. The SED + replacement files are no longer used to handle localization. + + + + The render, help and + locale functionalities were consolidated + as the most frequent tasks performed inside the repository. + Additionally, the prepare and tuneup functionalities are also + maintained as useful tasks. + + + + In the documentation area, support for producing localized + transformations of DocBook XML DTD instances was added through + the render and locale functionalities. + The render functionality uses the + xsltproc command-line XSLT parser in + conjunction with the styles provided by the + docbook-style-xsl package, both of them + included inside The CentOS Distribution. The locale + functionality creates the localized portable object + (PO) the render + functionality needs to produce localized transformations of + DocBook XML DTD instances. + + + + To build DocBook documentation, it was considered the idea of + using concepts behind repository directory structure as base, + not the opposite (as I've been doing with Texinfo backend, so + far). + + + + Producing documentation through DocBook XML as default + documentation backend consolidates render + and locale even more. In this + configuration, once the DocBook files are written, you use + locale functionality to localize the + DocBook files in your prefered language and later, using + render functionality, you produce the + XTHML and PDF outputs as specified in a XSLT or DSL + customization layer. + + + diff --git a/Manuals/Repository/Docbook/Repository/Layout.docbook b/Manuals/Repository/Docbook/Repository/Layout.docbook new file mode 100644 index 0000000..46fc98b --- /dev/null +++ b/Manuals/Repository/Docbook/Repository/Layout.docbook @@ -0,0 +1,63 @@ + + + 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. + + + &repo-layout-filenames; + &repo-layout-relbdirs; + &repo-layout-syncpaths; + &repo-layout-extending; + + diff --git a/Manuals/Repository/Docbook/Repository/Layout/extending.docbook b/Manuals/Repository/Docbook/Repository/Layout/extending.docbook new file mode 100644 index 0000000..d99c721 --- /dev/null +++ b/Manuals/Repository/Docbook/Repository/Layout/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/Repository/Docbook/Repository/Layout/filenames.docbook b/Manuals/Repository/Docbook/Repository/Layout/filenames.docbook new file mode 100644 index 0000000..6941b4e --- /dev/null +++ b/Manuals/Repository/Docbook/Repository/Layout/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/Repository/Docbook/Repository/Layout/relbdirs.docbook b/Manuals/Repository/Docbook/Repository/Layout/relbdirs.docbook new file mode 100644 index 0000000..967bb8e --- /dev/null +++ b/Manuals/Repository/Docbook/Repository/Layout/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/Repository/Docbook/Repository/Layout/syncpaths.docbook b/Manuals/Repository/Docbook/Repository/Layout/syncpaths.docbook new file mode 100644 index 0000000..7b4ec2d --- /dev/null +++ b/Manuals/Repository/Docbook/Repository/Layout/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/Repository/Docbook/Repository/Usage.docbook b/Manuals/Repository/Docbook/Repository/Usage.docbook new file mode 100644 index 0000000..b989fc4 --- /dev/null +++ b/Manuals/Repository/Docbook/Repository/Usage.docbook @@ -0,0 +1,66 @@ + + + Repository Usage Conditions + + + &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 layout, make local + changes, test the changes really work the way expected and + finally, request access to publish them up. + + + + Once you've received access to publish your changes and as + long as you behave as a good cooperating + citizen, there is no need for you to request + permission to publish new changes. + + + + 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. Repository + administrators have the reposability of creating new user's + account, setting permissions and revoking publishing rights to + ill-willed users, as well. + + + + 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/Repository/Worklines.docbook b/Manuals/Repository/Docbook/Repository/Worklines.docbook new file mode 100644 index 0000000..e07819f --- /dev/null +++ b/Manuals/Repository/Docbook/Repository/Worklines.docbook @@ -0,0 +1,21 @@ + + + Repository Work Lines + + + To organize content production inside &TCAR;, production has + been divided into individual work lines that relate one + 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. + + + &repo-worklines-identity; + &repo-worklines-l10n; + &repo-worklines-manuals; + &repo-worklines-scripts; + + diff --git a/Manuals/Repository/Docbook/Repository/Worklines/identity.docbook b/Manuals/Repository/Docbook/Repository/Worklines/identity.docbook new file mode 100644 index 0000000..78205e7 --- /dev/null +++ b/Manuals/Repository/Docbook/Repository/Worklines/identity.docbook @@ -0,0 +1,26 @@ + + + Visual 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 they look and + feel). + + + + Finally, 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. + + + diff --git a/Manuals/Repository/Docbook/Repository/Worklines/l10n.docbook b/Manuals/Repository/Docbook/Repository/Worklines/l10n.docbook new file mode 100644 index 0000000..8134155 --- /dev/null +++ b/Manuals/Repository/Docbook/Repository/Worklines/l10n.docbook @@ -0,0 +1,22 @@ + + + Localization + + + 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 GNU + gettext multi-lingual message + production tool set and xml2po command. + + + diff --git a/Manuals/Repository/Docbook/Repository/Worklines/manuals.docbook b/Manuals/Repository/Docbook/Repository/Worklines/manuals.docbook new file mode 100644 index 0000000..ef40f87 --- /dev/null +++ b/Manuals/Repository/Docbook/Repository/Worklines/manuals.docbook @@ -0,0 +1,20 @@ + + + Documentation + + + 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;. + + + + 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 and DocBook). + + + diff --git a/Manuals/Repository/Docbook/Repository/Worklines/scripts.docbook b/Manuals/Repository/Docbook/Repository/Worklines/scripts.docbook new file mode 100644 index 0000000..53780f9 --- /dev/null +++ b/Manuals/Repository/Docbook/Repository/Worklines/scripts.docbook @@ -0,0 +1,24 @@ + + + Automation + + + 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 centos-art.sh script and all + its functionalities (e.g., render for + rendition, help for documentation, + locale for localization, etc.) are + developed. + + + + 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/repository.docbook b/Manuals/Repository/Docbook/repository.docbook index 49d6d34..d98698c 100644 --- a/Manuals/Repository/Docbook/repository.docbook +++ b/Manuals/Repository/Docbook/repository.docbook @@ -5,7 +5,7 @@ - + @@ -14,7 +14,7 @@ %Commons.ent; %Preface.ent; -%Introduction.ent; +%Repository.ent; %Identity.ent; %Locales.ent; %Manuals.ent;