From 9c620793bf5126350f97934544941ed8d2ff989f Mon Sep 17 00:00:00 2001 From: Alain Reguera Delgado Date: Jun 22 2011 17:43:18 +0000 Subject: Update repository documentation manual in docbook format. --- diff --git a/Manuals/Repository/Docbook/Introduction.docbook b/Manuals/Repository/Docbook/Introduction.docbook index c83b0dc..cfc091d 100644 --- a/Manuals/Repository/Docbook/Introduction.docbook +++ b/Manuals/Repository/Docbook/Introduction.docbook @@ -26,6 +26,13 @@ &intro-history; - &intro-repoconvs; + &intro-copying; + &intro-policy; + &intro-worklines; + &intro-relbdirs; + &intro-syncpaths; + &intro-extending; + &intro-filenames; + &intro-layout; diff --git a/Manuals/Repository/Docbook/Introduction.ent b/Manuals/Repository/Docbook/Introduction.ent index 10e9549..6cf79cb 100644 --- a/Manuals/Repository/Docbook/Introduction.ent +++ b/Manuals/Repository/Docbook/Introduction.ent @@ -10,14 +10,13 @@ - - - - - - - - - + + + + + + + + diff --git a/Manuals/Repository/Docbook/Introduction/Copying.docbook b/Manuals/Repository/Docbook/Introduction/Copying.docbook new file mode 100644 index 0000000..20cdc88 --- /dev/null +++ b/Manuals/Repository/Docbook/Introduction/Copying.docbook @@ -0,0 +1,72 @@ + + + Repository Copying Conditions + + + ©RIGHT; + + + + &TCAS; uses &TCAR; to implement &TCPCVI;. The implementation + itself is controlled by the centos-art.sh + script. + + + + Both the centos-art.sh script and &TCAR;, + are not in the public domain; they are copyrighted and there + are restrictions on their distribution, but these restrictions + are designed to permit everything that a good cooperating + citizen would want to do. What is not allowed is to try to + prevent others from further sharing any version of this work + that they might get from you. + + + + Specifically, we want to make sure that you have the right to + give away copies of centos-art.sh script + and the organization of files it needs to work, that you + receive source code or else can get it if you want it, that + you can change this work or use pieces of it in new free + works, and that you know you can do these things. + + + + To make sure that everyone has such rights, we have to forbid + you to deprive anyone else of these rights. For example, if + you distribute copies of the centos-art.sh + script, you must give the recipients all the rights that you + have. You must make sure that they, too, receive or can get + the source code. And you must tell them their rights. + + + + Also, for our own protection, we must make certain that + everyone finds out that there is no warranty for the + centos-art.sh script. If this work is + modified by someone else and passed on, we want their + recipients to know that what they have is not what we + distributed, so that any problems introduced by others will + not reflect on our reputation. + + + + The centos-art.sh script is released as a + GPL work. Individual packages used by + centos-art.sh script include their own + licenses and the centos-art.sh script + license applies to all packages that it does not clash with. + If there is a clash between the + centos-art.sh script license and individual + package licenses, the individual package license applies + instead. + + + + The precise conditions of the license for the + centos-art.sh script are found in the . This manual specifically is covered + by the . + + + diff --git a/Manuals/Repository/Docbook/Introduction/Extending.docbook b/Manuals/Repository/Docbook/Introduction/Extending.docbook new file mode 100644 index 0000000..e0bfa67 --- /dev/null +++ b/Manuals/Repository/Docbook/Introduction/Extending.docbook @@ -0,0 +1,42 @@ + + + Extending Repository Organization + + + Occasionly, you may find that new components of &TCPCVI; need + to be added to the repository in order to work them out. If + that is the case, the first question we need to ask ourselves, + before starting to create directories blindly all over, is: + What is the right place to store it? + + + + When the repository structure is extended, it is very useful + to bear in mind &TCPCVIS;, &TCM; and &TCDRS;. The rest is a + matter of choosing appropriate names. It is also worth to + know that each directory in the repository responds to one or + more concepts that justify its existence. + + + + To build a directory structure inside the repository, you need + to define the concept behind it first and later create the + directory, remembering that there are locations inside the + repository that define concepts you probably would prefer to + reuse. For example, the trunk/Identity/Images/Themes + directory stores artistic motifs of different themes, the + trunk/Identity/Models/Themes + directory stores design models for themes, the trunk/Manuals directory stores + documentation, the trunk/L10n stores translation + messages, and the trunk/Scripts stores automation + scripts. Using this information and the one provided in , it is possible for you to + find out good places for extending &TCAR;. + + + diff --git a/Manuals/Repository/Docbook/Introduction/Filenames.docbook b/Manuals/Repository/Docbook/Introduction/Filenames.docbook new file mode 100644 index 0000000..fccaea7 --- /dev/null +++ b/Manuals/Repository/Docbook/Introduction/Filenames.docbook @@ -0,0 +1,27 @@ + + + Repository File Names + + + Inside &TCAR;, file names are all written in lowercase (e.g., + 01-welcome.png, + splash.png, + anaconda_header.png, etc.) and directory + names are all written capitalized (e.g., Identity, Themes, Motifs) and sometimes in cammel + case (e.g., TreeFlower, + etc.). + + + + In the very specific case of repository documentation entries, + file names follow the directory naming convenction. This is + because they are documenting directories and that is something + we want to remark. So, to better describe what we are + documenting, documentation entries follow the name convenction + used by the item they document. + + + diff --git a/Manuals/Repository/Docbook/Introduction/Layout.docbook b/Manuals/Repository/Docbook/Introduction/Layout.docbook new file mode 100644 index 0000000..4b29108 --- /dev/null +++ b/Manuals/Repository/Docbook/Introduction/Layout.docbook @@ -0,0 +1,60 @@ + + + Repository Layout + + + &TCAR; is supported by Subversion, a + version control system which allows you to keep old versions + of files and directories (usually source code), keep a log of + who, when, and why changes occurred, etc., like CVS, RCS or + SCCS. + + + + When using Subversion there is one source + repository and many working copies of + that source repository. The working copies are independent one + another, can be distributed all around the world and provide a + local place for designers, documentors, translators and + programmers to perform their work in a descentralized way. + The source repository, on the other hand, provides a central + place for all independent working copies to interchange data + and provides the information required to permit extracting + previous versions of files at any time. + + + + The first level of directories in the repository provides + organization through a convenctional trunk, + branches and tags layout. In + this configuration the trunk directory is where main + changes take place, the tags directory is where frozen + copies of trunk changes + are placed in for releasing, and the branches directory is an + intermediate place between trunk and tags states where changes take + place before being merged into trunk and finally released into + tags. + + + + The second level of directories in the repository provides + organization for each work line described in . + + + + All other subsequent levels of directories in the repository, + from third level on, are created to organize specific concepts + related to the work line they are in. A complete reference for + each directory inside &TCAR; is available at . + + + diff --git a/Manuals/Repository/Docbook/Introduction/Policy.docbook b/Manuals/Repository/Docbook/Introduction/Policy.docbook new file mode 100644 index 0000000..f2ee617 --- /dev/null +++ b/Manuals/Repository/Docbook/Introduction/Policy.docbook @@ -0,0 +1,66 @@ + + + Repository Policy + + + &TCAR; is a collaborative tool that anyone can have access to. + However, changing that tool in any form is something that + should be requested in &TCDML;. Generally, people download + working copies of &TCAR; to study its organization, make local + changes, test the changes really work the way expected and + finally, request access to commit them up to &TCAR; for others + to benefit from them. + + + + Once you've received access to commit your changes, there is + no need for you to request permission again to commit other + changes from your working copy to &TCAR; as long as you behave + as a good cooperating citizen. + Otherwise, your rights to commit changes might be temporarly + revoked or permanently banished. + + + + As a good cooperating citizen one understand of a person who + respects the work already done by others and share ideas with + authors before changing relevant parts of their work, + specially in situations when the access required to realize + the changes has been granted already. Of course, there is a + time when conversation has taken place, the paths has been + traced and changing the work is so obvious that there is no + need for you to talk about it; that's because you already did, + you already built the trust to keep going. As complement, the + mailing list mentioned above is available for sharing ideas in + a way that good relationship between community citizens could + be constantly balanced. + + + + The relationship between community citizens is monitored by + repository administrators. Repository administrators are + responsible of granting that everything goes the way it needs + to go in order for &TCAR; to accomplish its mission which is: + to provide a colaborative tool for &TCC; where &TCPCVI; could + be built and maintained by &TCC; itself. + + + + The content produced inside &TCAR; is copyright of &TCAS; and + this is something you, as author, need to be aware of because + you are giving part of your creation's rights to someone else; + &TCAS; for this matter. In this case, your work is + distributed using &TCAS; as copyright holder not your name. + Because &TCAS; is the copyright holder, is the license chosen + by &TCAS; the one applied to your work, so it is the one you + need to agree with before making a creation inside &TCAR;. + + + + We belive that working together is far better than working + alone; eventhough somtimes, working alone is the only possible + way of reaching the state of glory which is to work + syncronized all together in freedom. + + + diff --git a/Manuals/Repository/Docbook/Introduction/Relbdirs.docbook b/Manuals/Repository/Docbook/Introduction/Relbdirs.docbook new file mode 100644 index 0000000..48e2f81 --- /dev/null +++ b/Manuals/Repository/Docbook/Introduction/Relbdirs.docbook @@ -0,0 +1,128 @@ + + + Relation Between Directories + + + In order for automation scripts to produce content inside a + working copy of &TCAR;, it is required that all work lines be + related somehow. The relation between work lines is used by + automation scripts to know where to retrive the information + they need to work with (e.g., input files, translation + messages, output locations, etc.). This kind of relation is + built using two path constructions known as master + paths and auxiliar paths. + + + + + Master Paths + + + A master path refers to a directory inside the repository that + contain input files required to produce output files through + automation scripts. Examples of master paths inside the + repository include: + + + + + trunk/Identity/Models/Brands + + + + + trunk/Manuals/Repository/Docbook + + + + + trunk/Identity/Models/Themes/Default/Distro/5/Anaconda + + + + + + + + + Auxiliar paths + + + An auxiliar path refers a directory inside the repository + considered auxiliar for the master path. Auxiliar path can be + either for output or localization. Assuming the master path + provides the input information, the auxiliar paths provide the + auxiliar information which describes how and where that input + information is rendered by automation scripts. Examples of + auxiliar paths inside the repository include: + + + + + trunk/Identity/Images/Brands + + + + + trunk/Manuals/Repository/Docbook/es_ES + + + + + trunk/Locales/Manuals/Repository/Docbook/es_ES + + + + + trunk/Identity/Images/Themes/Flame/3/Distro/5/Anaconda/es_ES + + + + + trunk/Locales/Identity/Models/Default/Distro/5/Anaconda/es_ES + + + + + + + + + + + The relationship between master and auxiliar paths is built by + combining the second directory level of master paths with + directories in the second directory level of repository + layout. In the second directory level of repository layout, + the Identity, Manuals and Scripts directories are always + used to create the master paths and the output auxiliar paths. + The Locales directory, + on the other hand, is always used to create localization + auxiliar paths for all the master paths available under + Identity, Manuals and Scripts directories. + + + + For example, if the LANG environment variable + is set to es_ES.UTF-8 and you execute the + render functionality of + centos-art.sh script with the trunk/Manuals/Repository/Docbook + master path as argument, it will produce &TCARUG; in Spanish + language using translation messages from trunk/Locales/Manuals/Repository/Docbook/es_ES + auxiliar path and saving output files inside trunk/Manuals/Repository/Docbook/es_ES + auxiliar path. + + + + To better understand what each directory inside the repository + means, read . + + + diff --git a/Manuals/Repository/Docbook/Introduction/Repoconvs.docbook b/Manuals/Repository/Docbook/Introduction/Repoconvs.docbook deleted file mode 100644 index 0e7873b..0000000 --- a/Manuals/Repository/Docbook/Introduction/Repoconvs.docbook +++ /dev/null @@ -1,14 +0,0 @@ - - - Repository Convenctions - - &intro-repoconvs-copying; - &intro-repoconvs-policy; - &intro-repoconvs-worklines; - &intro-repoconvs-relbdirs; - &intro-repoconvs-syncpaths; - &intro-repoconvs-extending; - &intro-repoconvs-filenames; - &intro-repoconvs-layout; - - diff --git a/Manuals/Repository/Docbook/Introduction/Repoconvs/copying.docbook b/Manuals/Repository/Docbook/Introduction/Repoconvs/copying.docbook deleted file mode 100644 index 1d4508f..0000000 --- a/Manuals/Repository/Docbook/Introduction/Repoconvs/copying.docbook +++ /dev/null @@ -1,72 +0,0 @@ - - - Copying Conditions - - - ©RIGHT; - - - - &TCAS; uses &TCAR; to implement &TCPCVI;. The implementation - itself is controlled by the centos-art.sh - script. - - - - Both the centos-art.sh script and &TCAR;, - are not in the public domain; they are copyrighted and there - are restrictions on their distribution, but these restrictions - are designed to permit everything that a good cooperating - citizen would want to do. What is not allowed is to try to - prevent others from further sharing any version of this work - that they might get from you. - - - - Specifically, we want to make sure that you have the right to - give away copies of centos-art.sh script - and the organization of files it needs to work, that you - receive source code or else can get it if you want it, that - you can change this work or use pieces of it in new free - works, and that you know you can do these things. - - - - To make sure that everyone has such rights, we have to forbid - you to deprive anyone else of these rights. For example, if - you distribute copies of the centos-art.sh - script, you must give the recipients all the rights that you - have. You must make sure that they, too, receive or can get - the source code. And you must tell them their rights. - - - - Also, for our own protection, we must make certain that - everyone finds out that there is no warranty for the - centos-art.sh script. If this work is - modified by someone else and passed on, we want their - recipients to know that what they have is not what we - distributed, so that any problems introduced by others will - not reflect on our reputation. - - - - The centos-art.sh script is released as a - GPL work. Individual packages used by - centos-art.sh script include their own - licenses and the centos-art.sh script - license applies to all packages that it does not clash with. - If there is a clash between the - centos-art.sh script license and individual - package licenses, the individual package license applies - instead. - - - - The precise conditions of the license for the - centos-art.sh script are found in the . This manual specifically is covered - by the . - - - diff --git a/Manuals/Repository/Docbook/Introduction/Repoconvs/extending.docbook b/Manuals/Repository/Docbook/Introduction/Repoconvs/extending.docbook deleted file mode 100644 index d974d41..0000000 --- a/Manuals/Repository/Docbook/Introduction/Repoconvs/extending.docbook +++ /dev/null @@ -1,42 +0,0 @@ - - - Extending Repository Organization - - - Occasionly, you may find that new components of &TCPCVI; need - to be added to the repository in order to work them out. If - that is the case, the first question we need to ask ourselves, - before starting to create directories blindly all over, is: - What is the right place to store it? - - - - When the repository structure is extended, it is very useful - to bear in mind &TCPCVIS;, &TCM; and &TCDRS;. The rest is a - matter of choosing appropriate names. It is also worth to - know that each directory in the repository responds to one or - more concepts that justify its existence. - - - - To build a directory structure inside the repository, you need - to define the concept behind it first and later create the - directory, remembering that there are locations inside the - repository that define concepts you probably would prefer to - reuse. For example, the trunk/Identity/Images/Themes - directory stores artistic motifs of different themes, the - trunk/Identity/Models/Themes - directory stores design models for themes, the trunk/Manuals directory stores - documentation, the trunk/L10n stores translation - messages, and the trunk/Scripts stores automation - scripts. Using this information and the one provided in , it is possible for you to - find out good places for extending &TCAR;. - - - diff --git a/Manuals/Repository/Docbook/Introduction/Repoconvs/filenames.docbook b/Manuals/Repository/Docbook/Introduction/Repoconvs/filenames.docbook deleted file mode 100644 index 777bb74..0000000 --- a/Manuals/Repository/Docbook/Introduction/Repoconvs/filenames.docbook +++ /dev/null @@ -1,27 +0,0 @@ - - - File Names - - - Inside &TCAR;, file names are all written in lowercase (e.g., - 01-welcome.png, - splash.png, - anaconda_header.png, etc.) and directory - names are all written capitalized (e.g., Identity, Themes, Motifs) and sometimes in cammel - case (e.g., TreeFlower, - etc.). - - - - In the very specific case of repository documentation entries, - file names follow the directory naming convenction. This is - because they are documenting directories and that is something - we want to remark. So, to better describe what we are - documenting, documentation entries follow the name convenction - used by the item they document. - - - diff --git a/Manuals/Repository/Docbook/Introduction/Repoconvs/layout.docbook b/Manuals/Repository/Docbook/Introduction/Repoconvs/layout.docbook deleted file mode 100644 index 6634f7c..0000000 --- a/Manuals/Repository/Docbook/Introduction/Repoconvs/layout.docbook +++ /dev/null @@ -1,60 +0,0 @@ - - - The Repository Layout - - - &TCAR; is supported by Subversion, a - version control system which allows you to keep old versions - of files and directories (usually source code), keep a log of - who, when, and why changes occurred, etc., like CVS, RCS or - SCCS. - - - - When using Subversion there is one source - repository and many working copies of - that source repository. The working copies are independent one - another, can be distributed all around the world and provide a - local place for designers, documentors, translators and - programmers to perform their work in a descentralized way. - The source repository, on the other hand, provides a central - place for all independent working copies to interchange data - and provides the information required to permit extracting - previous versions of files at any time. - - - - The first level of directories in the repository provides - organization through a convenctional trunk, - branches and tags layout. In - this configuration the trunk directory is where main - changes take place, the tags directory is where frozen - copies of trunk changes - are placed in for releasing, and the branches directory is an - intermediate place between trunk and tags states where changes take - place before being merged into trunk and finally released into - tags. - - - - The second level of directories in the repository provides - organization for each work line described in . - - - - All other subsequent levels of directories in the repository, - from third level on, are created to organize specific concepts - related to the work line they are in. A complete reference for - each directory inside &TCAR; is available at . - - - diff --git a/Manuals/Repository/Docbook/Introduction/Repoconvs/policy.docbook b/Manuals/Repository/Docbook/Introduction/Repoconvs/policy.docbook deleted file mode 100644 index eafdfa6..0000000 --- a/Manuals/Repository/Docbook/Introduction/Repoconvs/policy.docbook +++ /dev/null @@ -1,66 +0,0 @@ - - - Policy - - - &TCAR; is a collaborative tool that anyone can have access to. - However, changing that tool in any form is something that - should be requested in &TCDML;. Generally, people download - working copies of &TCAR; to study its organization, make local - changes, test the changes really work the way expected and - finally, request access to commit them up to &TCAR; for others - to benefit from them. - - - - Once you've received access to commit your changes, there is - no need for you to request permission again to commit other - changes from your working copy to &TCAR; as long as you behave - as a good cooperating citizen. - Otherwise, your rights to commit changes might be temporarly - revoked or permanently banished. - - - - As a good cooperating citizen one understand of a person who - respects the work already done by others and share ideas with - authors before changing relevant parts of their work, - specially in situations when the access required to realize - the changes has been granted already. Of course, there is a - time when conversation has taken place, the paths has been - traced and changing the work is so obvious that there is no - need for you to talk about it; that's because you already did, - you already built the trust to keep going. As complement, the - mailing list mentioned above is available for sharing ideas in - a way that good relationship between community citizens could - be constantly balanced. - - - - The relationship between community citizens is monitored by - repository administrators. Repository administrators are - responsible of granting that everything goes the way it needs - to go in order for &TCAR; to accomplish its mission which is: - to provide a colaborative tool for &TCC; where &TCPCVI; could - be built and maintained by &TCC; itself. - - - - The content produced inside &TCAR; is copyright of &TCAS; and - this is something you, as author, need to be aware of because - you are giving part of your creation's rights to someone else; - &TCAS; for this matter. In this case, your work is - distributed using &TCAS; as copyright holder not your name. - Because &TCAS; is the copyright holder, is the license chosen - by &TCAS; the one applied to your work, so it is the one you - need to agree with before making a creation inside &TCAR;. - - - - We belive that working together is far better than working - alone; eventhough somtimes, working alone is the only possible - way of reaching the state of glory which is to work - syncronized all together in freedom. - - - diff --git a/Manuals/Repository/Docbook/Introduction/Repoconvs/relbdirs.docbook b/Manuals/Repository/Docbook/Introduction/Repoconvs/relbdirs.docbook deleted file mode 100644 index fda4b5f..0000000 --- a/Manuals/Repository/Docbook/Introduction/Repoconvs/relbdirs.docbook +++ /dev/null @@ -1,128 +0,0 @@ - - - Relation Between Directories - - - In order for automation scripts to produce content inside a - working copy of &TCAR;, it is required that all work lines be - related somehow. The relation between work lines is used by - automation scripts to know where to retrive the information - they need to work with (e.g., input files, translation - messages, output locations, etc.). This kind of relation is - built using two path constructions known as master - paths and auxiliar paths. - - - - - Master Paths - - - A master path refers to a directory inside the repository that - contain input files required to produce output files through - automation scripts. Examples of master paths inside the - repository include: - - - - - trunk/Identity/Models/Brands - - - - - trunk/Manuals/Repository/Docbook - - - - - trunk/Identity/Models/Themes/Default/Distro/5/Anaconda - - - - - - - - - Auxiliar paths - - - An auxiliar path refers a directory inside the repository - considered auxiliar for the master path. Auxiliar path can be - either for output or localization. Assuming the master path - provides the input information, the auxiliar paths provide the - auxiliar information which describes how and where that input - information is rendered by automation scripts. Examples of - auxiliar paths inside the repository include: - - - - - trunk/Identity/Images/Brands - - - - - trunk/Manuals/Repository/Docbook/es_ES - - - - - trunk/Locales/Manuals/Repository/Docbook/es_ES - - - - - trunk/Identity/Images/Themes/Flame/3/Distro/5/Anaconda/es_ES - - - - - trunk/Locales/Identity/Models/Default/Distro/5/Anaconda/es_ES - - - - - - - - - - - The relationship between master and auxiliar paths is built by - combining the second directory level of master paths with - directories in the second directory level of repository - layout. In the second directory level of repository layout, - the Identity, Manuals and Scripts directories are always - used to create the master paths and the output auxiliar paths. - The Locales directory, - on the other hand, is always used to create localization - auxiliar paths for all the master paths available under - Identity, Manuals and Scripts directories. - - - - For example, if the LANG environment variable - is set to es_ES.UTF-8 and you execute the - render functionality of - centos-art.sh script with the trunk/Manuals/Repository/Docbook - master path as argument, it will produce &TCARUG; in Spanish - language using translation messages from trunk/Locales/Manuals/Repository/Docbook/es_ES - auxiliar path and saving output files inside trunk/Manuals/Repository/Docbook/es_ES - auxiliar path. - - - - To better understand what each directory inside the repository - means, read . - - - diff --git a/Manuals/Repository/Docbook/Introduction/Repoconvs/syncpaths.docbook b/Manuals/Repository/Docbook/Introduction/Repoconvs/syncpaths.docbook deleted file mode 100644 index a651c66..0000000 --- a/Manuals/Repository/Docbook/Introduction/Repoconvs/syncpaths.docbook +++ /dev/null @@ -1,93 +0,0 @@ - - - Syncronizing Paths - - - Once both master and auxiliar paths have been set in the - repository, they shouldn't be changed. However, assuming you - need to change them, it is required that you also change the - relation between them, in order for both master and auxiliar - paths to retain their relation one another. This process of - keeping relation between master and auxiliar paths updated is - known as path syncronization. - - - - Path syncronization is required for automation scripts to know - where to store final output, where to retrive translation, and - any information that might be desired. If the relation between - master paths and auxiliar paths is lost, there is no way for - centos-art.sh script to know where to - retrive the information it needs to work with. Path - syncronization is the way we use to organize and extend the - information stored in the repository. - - - - Path syncronization involves both movement of files and - replacement of content inside files. Movement of files is - related to actions like renaming files and directories inside - the repository. Replacement of content inside files is - related to actions like replacing information (e.g., paths - information) inside files in order to keep file contents and - file locations consistent one another after the movement. - - - - The order followed to syncronize path information is very - important because the versioned nature of the files we are - working with. When a renaming action is performed, we avoid - making replacements inside files first and file movements - later. This would require two commit actions: one for the - files' internal changes and another for the file movement - itself. Otherwise, we prefer to perform file movements first - and file internal replacements later. This way it is possible - to commit both changes as if they were just one. - - - - - There is no support for URLs actions inside - centos-art.sh script. The - centos-art.sh script is designed to - work with local files inside the working copy only. If you - need to perform URL actions directly, use Subversion - commands instead. - - - - - At this moment there is no full implementation of path - syncronization process inside centos-art.sh - script and it is somthing we need to do oursleves. However, - the texinfo backend of help - functionality which provides a restricted implementation of - path syncronization to this specific area of documentation - through the , - and options you can take as - reference to implement it in other areas. - - - - The plan for a full implementation of path syncronization - would be to create individual restricted implementations like - the one in texinfo backend for other areas that - demand it and then, create a higher implmentation that - combines them all as needed. This way, if we try to rename a - repository directory the higher action will define which are - all the restricted actions that should be performed in order - to make the full path syncronization. - - - - For example, if the directory we are renaming is a master - path, it is required to syncronize the related output and - localization auxiliar paths. On the other hand, if the - directory we are renaming through full path syncronization is - an auxiliar path, it is required to determine first what is - the related master path and later, perform the syncronization - from master path to auxiliar paths as if the path provided - would be the master path not the auxiliar path. - - - diff --git a/Manuals/Repository/Docbook/Introduction/Repoconvs/worklines.docbook b/Manuals/Repository/Docbook/Introduction/Repoconvs/worklines.docbook deleted file mode 100644 index b04524c..0000000 --- a/Manuals/Repository/Docbook/Introduction/Repoconvs/worklines.docbook +++ /dev/null @@ -1,93 +0,0 @@ - - - Work Lines - - - To organize content production inside &TCAR;, production has - been divided into individual work lines that relate one - another. The is based on the idea of doing one thing well and - later combine the result of each individual part to achieve a - higher purpose. Work lines, as conceived here, provide - relayable output components that combine one another to close - the production cycle inside &TCAR;. - - - - - Visual Identity (trunk/Identity) - - - In the production cycle, the first step takes place through - graphic design. It is focused on preparing design models for - all the visual manifestation &TCP; is made of. Here, graphic - designers describe the visual characteristics of each visual - manifestation (e.g., image dimensions, position of text in the - visible area, translation markers, etc.). Later, once design - models have been defined, graphic designers take care of - artistic motifs to define the visual style of those design - models already created (e.g., how the look and feel). - Furthermore, graphic designers use the - render functionality of - centos-art.sh script to combine both design - models and artistic motifs in order to produce the final - images required by each visual manifestaions. - - - - - - Localization (trunk/L10n) - - - The second step in the production cycle is to localize - source files (e.g., SVG, DocBook, Shell scripts). This step - makes possible to produce localized images, localized - documentation and localized automation scripts. The - localization tasks are carried on by translators using the - locale functionality of the - centos-art.sh script which take care of - retriving translatable strings from source files and provide a - consistent localization interface based on the ideas behind - GNU gettext multi-lingual message - production. - - - - - - Documentation (trunk/Manuals) - - - The third step in the production cycle is to document &TCAR;, - what it is and how to use it. This step provides the - conceptual ideas used as base to edificate &TCPCVI; and is - implemented by mean of &TCARUG;. To write documentation, - documentors use the help functionality of - centos-art.sh script which provide an - consistent interface for building documentation through - different documentation backends (e.g., Texinfo, DocBook). - - - - - - Automation (trunk/Scripts) - - - The fourth step in the production cycle is to automate - frequent tasks inside &TCAR;. This step closes the production - cycle and provides the production standards needed by all - different work lines to coexist together. Here is where we - develop the centos-art.sh script and all - its functionalities (e.g., render for - rendition, help for documentation, - locale for localization, etc.). At this - point it should be obvious, but we consider worth to remember - that: there is no need to type several tasks, time after time, - if they can be programmed into just one executable script. - - - - - - diff --git a/Manuals/Repository/Docbook/Introduction/Syncpaths.docbook b/Manuals/Repository/Docbook/Introduction/Syncpaths.docbook new file mode 100644 index 0000000..3d6245b --- /dev/null +++ b/Manuals/Repository/Docbook/Introduction/Syncpaths.docbook @@ -0,0 +1,93 @@ + + + Syncronizing Paths + + + Once both master and auxiliar paths have been set in the + repository, they shouldn't be changed. However, assuming you + need to change them, it is required that you also change the + relation between them, in order for both master and auxiliar + paths to retain their relation one another. This process of + keeping relation between master and auxiliar paths updated is + known as path syncronization. + + + + Path syncronization is required for automation scripts to know + where to store final output, where to retrive translation, and + any information that might be desired. If the relation between + master paths and auxiliar paths is lost, there is no way for + centos-art.sh script to know where to + retrive the information it needs to work with. Path + syncronization is the way we use to organize and extend the + information stored in the repository. + + + + Path syncronization involves both movement of files and + replacement of content inside files. Movement of files is + related to actions like renaming files and directories inside + the repository. Replacement of content inside files is + related to actions like replacing information (e.g., paths + information) inside files in order to keep file contents and + file locations consistent one another after the movement. + + + + The order followed to syncronize path information is very + important because the versioned nature of the files we are + working with. When a renaming action is performed, we avoid + making replacements inside files first and file movements + later. This would require two commit actions: one for the + files' internal changes and another for the file movement + itself. Otherwise, we prefer to perform file movements first + and file internal replacements later. This way it is possible + to commit both changes as if they were just one. + + + + + There is no support for URLs actions inside + centos-art.sh script. The + centos-art.sh script is designed to + work with local files inside the working copy only. If you + need to perform URL actions directly, use Subversion + commands instead. + + + + + At this moment there is no full implementation of path + syncronization process inside centos-art.sh + script and it is somthing we need to do oursleves. However, + the texinfo backend of help + functionality which provides a restricted implementation of + path syncronization to this specific area of documentation + through the , + and options you can take as + reference to implement it in other areas. + + + + The plan for a full implementation of path syncronization + would be to create individual restricted implementations like + the one in texinfo backend for other areas that + demand it and then, create a higher implmentation that + combines them all as needed. This way, if we try to rename a + repository directory the higher action will define which are + all the restricted actions that should be performed in order + to make the full path syncronization. + + + + For example, if the directory we are renaming is a master + path, it is required to syncronize the related output and + localization auxiliar paths. On the other hand, if the + directory we are renaming through full path syncronization is + an auxiliar path, it is required to determine first what is + the related master path and later, perform the syncronization + from master path to auxiliar paths as if the path provided + would be the master path not the auxiliar path. + + + diff --git a/Manuals/Repository/Docbook/Introduction/Worklines.docbook b/Manuals/Repository/Docbook/Introduction/Worklines.docbook new file mode 100644 index 0000000..14beb48 --- /dev/null +++ b/Manuals/Repository/Docbook/Introduction/Worklines.docbook @@ -0,0 +1,93 @@ + + + Repository Work Lines + + + To organize content production inside &TCAR;, production has + been divided into individual work lines that relate one + another. The is based on the idea of doing one thing well and + later combine the result of each individual part to achieve a + higher purpose. Work lines, as conceived here, provide + relayable output components that combine one another to close + the production cycle inside &TCAR;. + + + + + Visual Identity (trunk/Identity) + + + In the production cycle, the first step takes place through + graphic design. It is focused on preparing design models for + all the visual manifestation &TCP; is made of. Here, graphic + designers describe the visual characteristics of each visual + manifestation (e.g., image dimensions, position of text in the + visible area, translation markers, etc.). Later, once design + models have been defined, graphic designers take care of + artistic motifs to define the visual style of those design + models already created (e.g., how the look and feel). + Furthermore, graphic designers use the + render functionality of + centos-art.sh script to combine both design + models and artistic motifs in order to produce the final + images required by each visual manifestaions. + + + + + + Localization (trunk/L10n) + + + The second step in the production cycle is to localize + source files (e.g., SVG, DocBook, Shell scripts). This step + makes possible to produce localized images, localized + documentation and localized automation scripts. The + localization tasks are carried on by translators using the + locale functionality of the + centos-art.sh script which take care of + retriving translatable strings from source files and provide a + consistent localization interface based on the ideas behind + GNU gettext multi-lingual message + production. + + + + + + Documentation (trunk/Manuals) + + + The third step in the production cycle is to document &TCAR;, + what it is and how to use it. This step provides the + conceptual ideas used as base to edificate &TCPCVI; and is + implemented by mean of &TCARUG;. To write documentation, + documentors use the help functionality of + centos-art.sh script which provide an + consistent interface for building documentation through + different documentation backends (e.g., Texinfo, DocBook). + + + + + + Automation (trunk/Scripts) + + + The fourth step in the production cycle is to automate + frequent tasks inside &TCAR;. This step closes the production + cycle and provides the production standards needed by all + different work lines to coexist together. Here is where we + develop the centos-art.sh script and all + its functionalities (e.g., render for + rendition, help for documentation, + locale for localization, etc.). At this + point it should be obvious, but we consider worth to remember + that: there is no need to type several tasks, time after time, + if they can be programmed into just one executable script. + + + + + +