diff --git a/Manuals/Docbook/Entities/Repository/Usage/Worklines.docbook b/Manuals/Docbook/Entities/Repository/Usage/Worklines.docbook new file mode 100644 index 0000000..666d3e0 --- /dev/null +++ b/Manuals/Docbook/Entities/Repository/Usage/Worklines.docbook @@ -0,0 +1,23 @@ + + + + Work lines + + Inside CentOS Artwork Repository there are four major work + lines of production which are: graphic design, documentation, + localization and automation. These work lines describe different + areas of content production. Content production inside these + specific areas may vary as much as persons be working on them. + Producing content in too many different ways may result + innapropriate in a collaborative environment like CentOS Artwork + Repository where content produced in one area depends somehow from + content produced in another different area. So, a content + production standard is required for each available work + line. + + &repo-usage-section-4-1; + &repo-usage-section-4-2; + &repo-usage-section-4-3; + &repo-usage-section-4-4; + + diff --git a/Manuals/Docbook/Entities/Repository/Usage/Worklines/automation.docbook b/Manuals/Docbook/Entities/Repository/Usage/Worklines/automation.docbook new file mode 100644 index 0000000..f6fb5a5 --- /dev/null +++ b/Manuals/Docbook/Entities/Repository/Usage/Worklines/automation.docbook @@ -0,0 +1,18 @@ + + + + Automation + + The automation work line exists to standardize content + production inside the working copies of CentOS Artwork Repository. + Here is developed the centos-art.sh script, a + bash script specially designed to automate most frequent tasks + (e.g., rendition, documentation and localization) inside the + repository. There is no need to type several tasks, time after + time, if they can be programmed into just one executable + script. + + The automation work line is organized in the trunk/Scripts directory. + + diff --git a/Manuals/Docbook/Entities/Repository/Usage/Worklines/documentation.docbook b/Manuals/Docbook/Entities/Repository/Usage/Worklines/documentation.docbook new file mode 100644 index 0000000..574458b --- /dev/null +++ b/Manuals/Docbook/Entities/Repository/Usage/Worklines/documentation.docbook @@ -0,0 +1,14 @@ + + + + Documentation + + The documentation work line exists to describe what each + directory inside the CentOS Artwork Repository is for, the + conceptual ideas behind them and, if possible, how automation + scripts make use of them. + + The documentation work line is organized in the trunk/Manuals directory. + + diff --git a/Manuals/Docbook/Entities/Repository/Usage/Worklines/graphic-design.docbook b/Manuals/Docbook/Entities/Repository/Usage/Worklines/graphic-design.docbook new file mode 100644 index 0000000..c3727d8 --- /dev/null +++ b/Manuals/Docbook/Entities/Repository/Usage/Worklines/graphic-design.docbook @@ -0,0 +1,15 @@ + + + + Graphic design + + The graphic design work line exists to cover brand design, + typography design and themes design mainly. Additionally, some + auxiliar areas like icon design, illustration design, brushes + design, patterns designs and palettes of colors are also included + here for completeness. + + The graphic design work line is organized in the trunk/Identity directory. + + diff --git a/Manuals/Docbook/Entities/Repository/Usage/Worklines/localization.docbook b/Manuals/Docbook/Entities/Repository/Usage/Worklines/localization.docbook new file mode 100644 index 0000000..972a618 --- /dev/null +++ b/Manuals/Docbook/Entities/Repository/Usage/Worklines/localization.docbook @@ -0,0 +1,14 @@ + + + + Localization + + The localization work line exists to provide the translation + messages required to produce content in different languages. + Translation messages inside the repository are stored as portable + objects (e.g., .po, .pot) and machine objects (.mo). + + The localization work line is organized in the trunk/Locales directory. + + diff --git a/Manuals/Docbook/Entities/Repository/Usage/connection-between-worklines.docbook b/Manuals/Docbook/Entities/Repository/Usage/connection-between-worklines.docbook new file mode 100644 index 0000000..afe6e85 --- /dev/null +++ b/Manuals/Docbook/Entities/Repository/Usage/connection-between-worklines.docbook @@ -0,0 +1,44 @@ + + + + Connection between directories + + In order for automation scripts to produce content inside + working copies of CentOS Artwork Repository, it is required that + all work lines be connected somehow. Using this connection, + automation scripts can know where to retrive the information they + need to work with (e.g., design model, translation messages, + output locations, etc.). This connection is built using two path + constructions named master paths and + auxiliar paths. + + The master path points only to directories that contain + source files (e.g., SVG files) required to produce base content + (e.g., PNG files) through automation scripts. Each master path + inside the repository may have several auxiliar paths associated, + but auxiliar paths can only have one master path associated. + Master paths are organized under trunk/Identity/Models directory + structure and auxiliar paths under trunk/Identity/Images, trunk/Locales and trunk/Manuals directory + structures. + + The auxiliar paths can point either to directories or files. + When an auxiliar path points to a directory, that directory + contains information that modifies somehow the content produced + from master paths (e.g., translation messages) or provides the + output information required to know where to store the content + produced from master path. When an auxiliar path points to a + file, that file has no other purpose but to document the master + path it refers to. + + The relationship between auxiliar paths and master paths is + realized by combining the master path itself and the second level + directory structures of the repository. The master path is + considered the path identifier and the second level directory + structure taken from the repository is considered the common part + of the path where the path identifier is appended to. + + diff --git a/Manuals/Docbook/Entities/Repository/Usage/extending-repository.docbook b/Manuals/Docbook/Entities/Repository/Usage/extending-repository.docbook new file mode 100644 index 0000000..75ad32a --- /dev/null +++ b/Manuals/Docbook/Entities/Repository/Usage/extending-repository.docbook @@ -0,0 +1,75 @@ + + + + Extending repository organization + + Occasionly, you may find that new components of The CentOS + Project Corporate Identity 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 start to create directories blindly + all over, is: @emph{What is the right place to store it?} + + The best place to find answers is in The CentOS Community + (see page @url{http://wiki.centos.org/GettingHelp}), but going + there with hands empty is not good idea. It may give the + impression you don't really care about. Instead, consider the + following suggestions to find your own comprehension in order to + make your own propositions based on it. + + When extending respository structure it is very useful to + bear in mind The CentOS Project Corporate Identity Structure + (@pxref{Directories trunk Identity}) The CentOS Mission and The + CentOS Release Schema. The rest is just matter of choosing + appropriate names. It is also worth to know that each directory in + the repository responds to a conceptual idea that justifies its + existence. + + To build a directory structure, you need to define the + conceptual idea first and later create the directory. There are + some locations inside the repository that already define some + concepts you probably want to reuse. For example, + @file{trunk/Identity/Images/Themes} to store theme artistic + motifs, @file{trunk/Identity/Models/Themes} to store theme design + models, @file{trunk/Manual} to store documentation files, + @file{trunk/Locales} to store translation messages, + @file{trunk/Scripts} to store automation scripts and so on. + + To illustrate this desition process let's consider the + @file{trunk/Identity/Images/Themes/TreeFlower/3} directory + structure as example. This directory can be read as: the theme + development line of version @file{3} of @file{TreeFlower} artistic + motif. Additional, we can identify that artistic motifs are part + of themes as well as themes are part of The CentOS Project + Corporate Identity. These concepts are better described + independently in each documentation entry related to the directory + structure as it is respectively shown in the list of commands + bellow. + + + + centos-art help --read turnk + + + centos-art help --read turnk/Identity + + + centos-art help --read turnk/Identity/Images + + + centos-art help --read turnk/Identity/Images/Themes + + + centos-art help --read turnk/Identity/Images/Themes/TreeFlower + + + centos-art help --read turnk/Identity/Images/Themes/TreeFlower/3 + + + + + + The concepts behind other location can be found in the same + way described above, just change the path information used above + to the one you are trying to know concepts for. + + diff --git a/Manuals/Docbook/Entities/Repository/Usage/filenames.docbook b/Manuals/Docbook/Entities/Repository/Usage/filenames.docbook new file mode 100644 index 0000000..74614b2 --- /dev/null +++ b/Manuals/Docbook/Entities/Repository/Usage/filenames.docbook @@ -0,0 +1,17 @@ + + + + File names + + Inside the CentOS Artwork Repository, 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.). + + + diff --git a/Manuals/Docbook/Entities/Repository/Usage/organization.docbook b/Manuals/Docbook/Entities/Repository/Usage/organization.docbook new file mode 100644 index 0000000..e04ebac --- /dev/null +++ b/Manuals/Docbook/Entities/Repository/Usage/organization.docbook @@ -0,0 +1,10 @@ + + + + Organization + + The CentOS Artwork Repository organization is described in + the chapter . + + diff --git a/Manuals/Docbook/Entities/Repository/Usage/policy.docbook b/Manuals/Docbook/Entities/Repository/Usage/policy.docbook new file mode 100644 index 0000000..7d2fe65 --- /dev/null +++ b/Manuals/Docbook/Entities/Repository/Usage/policy.docbook @@ -0,0 +1,49 @@ + + + + Policy + + The CentOS Artwork Repository is a collaborative tool that + anyone can have access to. However, changing that tool in any form + is something that should be requested in the CentOS Developers mailing + list. Generally, people download working copies from + CentOS Artwork Repository, study the repository organization, make + some changes in their working copies, make some tests to verify + such changes do work the way expected and finally request access + to commit them up to the CentOS Artwork Repository (i.e., the + source repository) 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 CentOS Artwork Repository as + long as you behave as a good cooperating + citizen. Otherwise, your rights to commit changes might + be temporarly revoked or completly 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. Anyway, 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 everything goes the way it needs to go in + order for the CentOS Artwork Repository to accomplish its mission + which is: to provide a colaborative tool for The CentOS Community + where The CentOS Project Corporate Identity is built and + maintained by The CentOS Community itself. + + It is also important to remember that all source files + inside CentOS Artwork Repository should comply the terms of in order for them to remain + inside the repository. + + diff --git a/Manuals/Docbook/Entities/Repository/Usage/section-1.docbook b/Manuals/Docbook/Entities/Repository/Usage/section-1.docbook deleted file mode 100644 index 7d2fe65..0000000 --- a/Manuals/Docbook/Entities/Repository/Usage/section-1.docbook +++ /dev/null @@ -1,49 +0,0 @@ - - - - Policy - - The CentOS Artwork Repository is a collaborative tool that - anyone can have access to. However, changing that tool in any form - is something that should be requested in the CentOS Developers mailing - list. Generally, people download working copies from - CentOS Artwork Repository, study the repository organization, make - some changes in their working copies, make some tests to verify - such changes do work the way expected and finally request access - to commit them up to the CentOS Artwork Repository (i.e., the - source repository) 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 CentOS Artwork Repository as - long as you behave as a good cooperating - citizen. Otherwise, your rights to commit changes might - be temporarly revoked or completly 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. Anyway, 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 everything goes the way it needs to go in - order for the CentOS Artwork Repository to accomplish its mission - which is: to provide a colaborative tool for The CentOS Community - where The CentOS Project Corporate Identity is built and - maintained by The CentOS Community itself. - - It is also important to remember that all source files - inside CentOS Artwork Repository should comply the terms of in order for them to remain - inside the repository. - - diff --git a/Manuals/Docbook/Entities/Repository/Usage/section-2.docbook b/Manuals/Docbook/Entities/Repository/Usage/section-2.docbook deleted file mode 100644 index e04ebac..0000000 --- a/Manuals/Docbook/Entities/Repository/Usage/section-2.docbook +++ /dev/null @@ -1,10 +0,0 @@ - - - - Organization - - The CentOS Artwork Repository organization is described in - the chapter . - - diff --git a/Manuals/Docbook/Entities/Repository/Usage/section-3.docbook b/Manuals/Docbook/Entities/Repository/Usage/section-3.docbook deleted file mode 100644 index 74614b2..0000000 --- a/Manuals/Docbook/Entities/Repository/Usage/section-3.docbook +++ /dev/null @@ -1,17 +0,0 @@ - - - - File names - - Inside the CentOS Artwork Repository, 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.). - - - diff --git a/Manuals/Docbook/Entities/Repository/Usage/section-4-1.docbook b/Manuals/Docbook/Entities/Repository/Usage/section-4-1.docbook deleted file mode 100644 index c3727d8..0000000 --- a/Manuals/Docbook/Entities/Repository/Usage/section-4-1.docbook +++ /dev/null @@ -1,15 +0,0 @@ - - - - Graphic design - - The graphic design work line exists to cover brand design, - typography design and themes design mainly. Additionally, some - auxiliar areas like icon design, illustration design, brushes - design, patterns designs and palettes of colors are also included - here for completeness. - - The graphic design work line is organized in the trunk/Identity directory. - - diff --git a/Manuals/Docbook/Entities/Repository/Usage/section-4-2.docbook b/Manuals/Docbook/Entities/Repository/Usage/section-4-2.docbook deleted file mode 100644 index 574458b..0000000 --- a/Manuals/Docbook/Entities/Repository/Usage/section-4-2.docbook +++ /dev/null @@ -1,14 +0,0 @@ - - - - Documentation - - The documentation work line exists to describe what each - directory inside the CentOS Artwork Repository is for, the - conceptual ideas behind them and, if possible, how automation - scripts make use of them. - - The documentation work line is organized in the trunk/Manuals directory. - - diff --git a/Manuals/Docbook/Entities/Repository/Usage/section-4-3.docbook b/Manuals/Docbook/Entities/Repository/Usage/section-4-3.docbook deleted file mode 100644 index 972a618..0000000 --- a/Manuals/Docbook/Entities/Repository/Usage/section-4-3.docbook +++ /dev/null @@ -1,14 +0,0 @@ - - - - Localization - - The localization work line exists to provide the translation - messages required to produce content in different languages. - Translation messages inside the repository are stored as portable - objects (e.g., .po, .pot) and machine objects (.mo). - - The localization work line is organized in the trunk/Locales directory. - - diff --git a/Manuals/Docbook/Entities/Repository/Usage/section-4-4.docbook b/Manuals/Docbook/Entities/Repository/Usage/section-4-4.docbook deleted file mode 100644 index f6fb5a5..0000000 --- a/Manuals/Docbook/Entities/Repository/Usage/section-4-4.docbook +++ /dev/null @@ -1,18 +0,0 @@ - - - - Automation - - The automation work line exists to standardize content - production inside the working copies of CentOS Artwork Repository. - Here is developed the centos-art.sh script, a - bash script specially designed to automate most frequent tasks - (e.g., rendition, documentation and localization) inside the - repository. There is no need to type several tasks, time after - time, if they can be programmed into just one executable - script. - - The automation work line is organized in the trunk/Scripts directory. - - diff --git a/Manuals/Docbook/Entities/Repository/Usage/section-4.docbook b/Manuals/Docbook/Entities/Repository/Usage/section-4.docbook deleted file mode 100644 index 666d3e0..0000000 --- a/Manuals/Docbook/Entities/Repository/Usage/section-4.docbook +++ /dev/null @@ -1,23 +0,0 @@ - - - - Work lines - - Inside CentOS Artwork Repository there are four major work - lines of production which are: graphic design, documentation, - localization and automation. These work lines describe different - areas of content production. Content production inside these - specific areas may vary as much as persons be working on them. - Producing content in too many different ways may result - innapropriate in a collaborative environment like CentOS Artwork - Repository where content produced in one area depends somehow from - content produced in another different area. So, a content - production standard is required for each available work - line. - - &repo-usage-section-4-1; - &repo-usage-section-4-2; - &repo-usage-section-4-3; - &repo-usage-section-4-4; - - diff --git a/Manuals/Docbook/Entities/Repository/Usage/section-5.docbook b/Manuals/Docbook/Entities/Repository/Usage/section-5.docbook deleted file mode 100644 index afe6e85..0000000 --- a/Manuals/Docbook/Entities/Repository/Usage/section-5.docbook +++ /dev/null @@ -1,44 +0,0 @@ - - - - Connection between directories - - In order for automation scripts to produce content inside - working copies of CentOS Artwork Repository, it is required that - all work lines be connected somehow. Using this connection, - automation scripts can know where to retrive the information they - need to work with (e.g., design model, translation messages, - output locations, etc.). This connection is built using two path - constructions named master paths and - auxiliar paths. - - The master path points only to directories that contain - source files (e.g., SVG files) required to produce base content - (e.g., PNG files) through automation scripts. Each master path - inside the repository may have several auxiliar paths associated, - but auxiliar paths can only have one master path associated. - Master paths are organized under trunk/Identity/Models directory - structure and auxiliar paths under trunk/Identity/Images, trunk/Locales and trunk/Manuals directory - structures. - - The auxiliar paths can point either to directories or files. - When an auxiliar path points to a directory, that directory - contains information that modifies somehow the content produced - from master paths (e.g., translation messages) or provides the - output information required to know where to store the content - produced from master path. When an auxiliar path points to a - file, that file has no other purpose but to document the master - path it refers to. - - The relationship between auxiliar paths and master paths is - realized by combining the master path itself and the second level - directory structures of the repository. The master path is - considered the path identifier and the second level directory - structure taken from the repository is considered the common part - of the path where the path identifier is appended to. - - diff --git a/Manuals/Docbook/Entities/Repository/Usage/section-6.docbook b/Manuals/Docbook/Entities/Repository/Usage/section-6.docbook deleted file mode 100644 index 75b0e26..0000000 --- a/Manuals/Docbook/Entities/Repository/Usage/section-6.docbook +++ /dev/null @@ -1,72 +0,0 @@ - - - - Syncronizing path information - - Syncronizing path information is the action of keeping all - path information up to date in the repository. This action implies - both file movement and replacement of content inside files already - moved, in this very specific order. File movement is related to - actions like duplicate, delete and rename files and directories in - the repository. Replacement of content inside files is related to - replace information, path information in this case, inside files - in the repository. - - The order followed to syncronize path information is - relevant because the versioned nature of the files we are working - with. We don't perform file content replacement first because that - would imply a repository change which will immediatly demmand a - commit in order for actions like duplicate, delete or rename to - take place. However, if we perform file movement first, it is - possible to commit both file moved and file content replacements - as if they were just one change. In this case the file content - replacement takes palce in the target location that have been - duplicated or renamed, not the one use as source location. This - configuration is specially useful when files are renamed (i.e., - one file is copied from a source location to a target location and - then the source location of it is removed from repository). - - 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. - - When one master path is changed it is required that all - related auxiliar paths be changed, too. This is required in order - for master paths to retain their relation with auxiliar paths. - This way, automation scripts are able to know where to retrive - translation messages from, where to store final output images to - and where to look for documentation. If 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. - - The auxiliar paths should never be modified under any reason - but to satisfy the relationship with the master path. Liberal - change of auxiliar paths may suppress the conceptual idea they - were initially created for; and certainly, automation scripts may - stop working as expected. The update direction to rename path - information must be from master path to auxiliar path and never - the opposite. - - The relation between master and auxiliar paths is useful to - keep repository organized but introduce some complications when we - work with files that use master path information as reference to - build structural information. This is the case of repository - documentation manual source files where inclusions, menus, nodes - and cross references are built using master path information as - reference. Now, to see what kind of complication we are talking - about, consider what would happen to a structural definitions - (i.e., inlusions, menus, nodes and cross refereces) already set in - the manual from one master path that is suddenly renamed to - something different. If the path information is not syncronized, - at this point, we lose connection between the master path and the - auxiliar path created to store the related documentation entry, as - well as the related structural definitions that end up pointing to - a master path that no longer exist. - - The syncronization of path information is aimed to solve - these kind of issues. - - diff --git a/Manuals/Docbook/Entities/Repository/Usage/section-7.docbook b/Manuals/Docbook/Entities/Repository/Usage/section-7.docbook deleted file mode 100644 index 75ad32a..0000000 --- a/Manuals/Docbook/Entities/Repository/Usage/section-7.docbook +++ /dev/null @@ -1,75 +0,0 @@ - - - - Extending repository organization - - Occasionly, you may find that new components of The CentOS - Project Corporate Identity 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 start to create directories blindly - all over, is: @emph{What is the right place to store it?} - - The best place to find answers is in The CentOS Community - (see page @url{http://wiki.centos.org/GettingHelp}), but going - there with hands empty is not good idea. It may give the - impression you don't really care about. Instead, consider the - following suggestions to find your own comprehension in order to - make your own propositions based on it. - - When extending respository structure it is very useful to - bear in mind The CentOS Project Corporate Identity Structure - (@pxref{Directories trunk Identity}) The CentOS Mission and The - CentOS Release Schema. The rest is just matter of choosing - appropriate names. It is also worth to know that each directory in - the repository responds to a conceptual idea that justifies its - existence. - - To build a directory structure, you need to define the - conceptual idea first and later create the directory. There are - some locations inside the repository that already define some - concepts you probably want to reuse. For example, - @file{trunk/Identity/Images/Themes} to store theme artistic - motifs, @file{trunk/Identity/Models/Themes} to store theme design - models, @file{trunk/Manual} to store documentation files, - @file{trunk/Locales} to store translation messages, - @file{trunk/Scripts} to store automation scripts and so on. - - To illustrate this desition process let's consider the - @file{trunk/Identity/Images/Themes/TreeFlower/3} directory - structure as example. This directory can be read as: the theme - development line of version @file{3} of @file{TreeFlower} artistic - motif. Additional, we can identify that artistic motifs are part - of themes as well as themes are part of The CentOS Project - Corporate Identity. These concepts are better described - independently in each documentation entry related to the directory - structure as it is respectively shown in the list of commands - bellow. - - - - centos-art help --read turnk - - - centos-art help --read turnk/Identity - - - centos-art help --read turnk/Identity/Images - - - centos-art help --read turnk/Identity/Images/Themes - - - centos-art help --read turnk/Identity/Images/Themes/TreeFlower - - - centos-art help --read turnk/Identity/Images/Themes/TreeFlower/3 - - - - - - The concepts behind other location can be found in the same - way described above, just change the path information used above - to the one you are trying to know concepts for. - - diff --git a/Manuals/Docbook/Entities/Repository/Usage/syncronizing-paths.docbook b/Manuals/Docbook/Entities/Repository/Usage/syncronizing-paths.docbook new file mode 100644 index 0000000..75b0e26 --- /dev/null +++ b/Manuals/Docbook/Entities/Repository/Usage/syncronizing-paths.docbook @@ -0,0 +1,72 @@ + + + + Syncronizing path information + + Syncronizing path information is the action of keeping all + path information up to date in the repository. This action implies + both file movement and replacement of content inside files already + moved, in this very specific order. File movement is related to + actions like duplicate, delete and rename files and directories in + the repository. Replacement of content inside files is related to + replace information, path information in this case, inside files + in the repository. + + The order followed to syncronize path information is + relevant because the versioned nature of the files we are working + with. We don't perform file content replacement first because that + would imply a repository change which will immediatly demmand a + commit in order for actions like duplicate, delete or rename to + take place. However, if we perform file movement first, it is + possible to commit both file moved and file content replacements + as if they were just one change. In this case the file content + replacement takes palce in the target location that have been + duplicated or renamed, not the one use as source location. This + configuration is specially useful when files are renamed (i.e., + one file is copied from a source location to a target location and + then the source location of it is removed from repository). + + 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. + + When one master path is changed it is required that all + related auxiliar paths be changed, too. This is required in order + for master paths to retain their relation with auxiliar paths. + This way, automation scripts are able to know where to retrive + translation messages from, where to store final output images to + and where to look for documentation. If 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. + + The auxiliar paths should never be modified under any reason + but to satisfy the relationship with the master path. Liberal + change of auxiliar paths may suppress the conceptual idea they + were initially created for; and certainly, automation scripts may + stop working as expected. The update direction to rename path + information must be from master path to auxiliar path and never + the opposite. + + The relation between master and auxiliar paths is useful to + keep repository organized but introduce some complications when we + work with files that use master path information as reference to + build structural information. This is the case of repository + documentation manual source files where inclusions, menus, nodes + and cross references are built using master path information as + reference. Now, to see what kind of complication we are talking + about, consider what would happen to a structural definitions + (i.e., inlusions, menus, nodes and cross refereces) already set in + the manual from one master path that is suddenly renamed to + something different. If the path information is not syncronized, + at this point, we lose connection between the master path and the + auxiliar path created to store the related documentation entry, as + well as the related structural definitions that end up pointing to + a master path that no longer exist. + + The syncronization of path information is aimed to solve + these kind of issues. + +