Blame Manual/Introduction/repo-convenctions.texi

74c0c0
The CentOS Artwork Repository is supported by Subversion
74c0c0
(@url{http://subversion.tigris.org/}), a version control system which
74c0c0
allows you to keep old versions of files and directories (usually
74c0c0
source code), keep a log of who, when, and why changes occurred, etc.,
513258
like CVS, RCS or SCCS.  
513258
513258
When using Subversion there is one @emph{source repository} and many
513258
@emph{working copies} of that source repository. The working copies
513258
are independent one another, can be distributed all around the world
513258
and provide a local place for designers, documentors, translators and
513258
programmers to perform their works in a descentralized way.  The
513258
source repository, on the other hand, provides a central place for all
513258
independent working copies to interchange data and provides the
74c0c0
information required to permit extracting previous versions of files
74c0c0
at any time.
74c0c0
0c08ea
@subsection Repository policy
41622d
@cindex Repository policy
74c0c0
32f4f2
The CentOS Artwork Repository is a collaborative tool that anyone can
32f4f2
have access to. However, changing that tool in any form is something
32f4f2
that should be requested in @email{centos-devel@@centos.org} mailing
32f4f2
list.  Generally, people download working copies from CentOS Artwork
32f4f2
Repository, study the repository organization, make some changes in
513258
their working copies, make some tests to verify such changes do work
513258
the way expected and finally request access to commit them up to the
513258
CentOS Artwork Repository (i.e., the source repository) for others to
513258
benefit from them.
74c0c0
74c0c0
Once you've received access to commit your changes, there is no need
74c0c0
for you to request permission again to commit other changes from your
74c0c0
working copy to CentOS Artwork Repository as long as you behave as a
74c0c0
@emph{good community citizen}.
74c0c0
513258
As a good community citizen one understand of a person who respects
74c0c0
the work already done for others and share ideas with authors before
74c0c0
changing relevant parts of their work, specially in situations when
513258
the access required to realize the changes has been granted already.
74c0c0
Of course, there is a time when conversation has taken place, the
74c0c0
paths has been traced and changing the work is so obvious that there
513258
is no need for you to talk about it; that's because you already did,
513258
you already built the trust to keep going. Anyway, the mailing list
74c0c0
mentioned above is available for sharing ideas in a way that good
74c0c0
relationship between community citizens could be constantly balanced.
74c0c0
74c0c0
The relationship between community citizens is monitored by repository
74c0c0
administrators. Repository administrators are responsible of granting
74c0c0
everything goes the way it needs to go in order for the CentOS Artwork
74c0c0
Repository to comply its mission which is: to provide a colaborative
74c0c0
tool for The CentOS Community where The CentOS Project Corporate
74c0c0
Identity is built and maintained from The CentOS Community itself.
74c0c0
74c0c0
It is also important to remember that all source files inside CentOS
74c0c0
Artwork Repository should comply the terms of GNU General Public
b81f10
License (@pxref{GNU General Public License}) in order for them to
b81f10
remain inside the repository.
74c0c0
0c08ea
@subsection Repository organization 
41622d
@cindex Repository organization
74c0c0
74c0c0
The CentOS Artwork Repository uses a @file{trunk}, @file{branches},
74c0c0
and @file{tags} organization.  
74c0c0
74c0c0
@table @file
74c0c0
@item trunk
74c0c0
74c0c0
The @file{trunk} directory organizes the main development line of
74c0c0
CentOS Artwork Repository. @xref{Directories trunk}, for more
74c0c0
information.
74c0c0
74c0c0
@item branches
74c0c0
513258
The @file{branches} directory oranizes intermediate development lines
74c0c0
taken from the main development line.  @xref{Directories branches},
74c0c0
for more information.
74c0c0
74c0c0
@item tags
74c0c0
74c0c0
The @file{tags} directory organizes frozen development lines taken
513258
either from the main or the intermediate lines of development.
74c0c0
@xref{Directories tags}, for more information.
74c0c0
@end table
87b0e4
0c08ea
@subsection Repository file names
41622d
@cindex Repository file names
87b0e4
513258
Inside the CentOS Artwork Repository, file names are all written in
513258
lowercase (e.g., @samp{01-welcome.png}, @samp{splash.png},
87b0e4
@samp{anaconda_header.png}, etc.) and directory names are all written
87b0e4
capitalized (e.g., @samp{Identity}, @samp{Themes}, @samp{Motifs},
87b0e4
@samp{TreeFlower}, etc.).
87b0e4
0c08ea
@subsection Repository work lines
c2929c
513258
Inside CentOS Artwork Repository there are four major work lines of
513258
production which are: @emph{graphic design}, @emph{documentation},
32f4f2
@emph{localization} and @emph{automation}.  These work lines describe
32f4f2
different areas of content production. Content production inside these
32f4f2
specific areas may vary as much as persons be working on them.
32f4f2
Producing content in too many different ways may result innapropriate
32f4f2
in a collaborative environment like CentOS Artwork Repository where
32f4f2
content produced in one area depends somehow from content produced in
513258
another different area. So, a @emph{content production standard} is
f67de1
required for each available work line.
87b0e4
0c08ea
@subsubsection Graphic design
41622d
@cindex Graphic design work line
798844
74c0c0
The graphic design work line exists to cover brand design, typography
513258
design and themes design mainly. Additionally, some auxiliar areas
f67de1
like icon design, illustration design, brushes design, patterns
f67de1
designs and palettes of colors are also included here for
f67de1
completeness.
74c0c0
74c0c0
Inside CentOS Artwork Repository graphic design is performed through
74c0c0
Inkscape (@url{http://www.inkscape.org/}) and GIMP
513258
(@url{http://www.gimp.org/}).  The Inkscape tool is used to create and
74c0c0
manipulate scalable vector graphics and export them to PNG format; it
74c0c0
also provides a command-line interface that we use to perform massive
513258
exportation from SVG files to PNG files in automation scripts. On the
513258
other hand, GIMP is used to create and manipulate rastered images,
513258
create brushes, patterns and palettes of colors.
74c0c0
74c0c0
@quotation
513258
@strong{Tip} Combine both Inkscape and GIMP specific functionalities
513258
and possibilities to produce very beautiful images.
74c0c0
@end quotation
74c0c0
513258
The CentOS Project Corporate Visual Identity is made of different
513258
visual manifestations (e.g., Distributions, Web sites, Stationery,
513258
etc.).  Visual manifestations implement the corporate identity
513258
concepts by mean of images.  To produce these images, we decompose
513258
image production in @emph{design models} and @emph{artistic motifs}.
74c0c0
74c0c0
Design models provide the structural information of images (i.e.,
513258
dimension, position of common elements in the visible area,
513258
translation markers, etc.) and they are generally produced as scalable
513258
vector graphics to take advantage of SVG standard, an XML-based
f67de1
standard.
513258
513258
Artistic motifs provide the visual style (i.e., the background
513258
information, the look and feel) some design models need to complete
513258
the final image produced by automation scripts. Artistic motifs are
513258
generally produced as rastered images.
513258
513258
The result produced from combining one design model with one artistic
c2929c
motif is what we know as a @emph{theme}. Inside themes directory
d8d967
structure (@pxref{Directories trunk Identity Images Themes}), you can find
513258
several design models and several artistic motifs independently one
513258
another that can be albitrarily combined through @emph{theme
c2929c
rendition}, a flexible way to produce images for different visual
513258
manifestations in very specific visual styles. Inside themes directory
513258
structure, theme rendition is performed in
d8d967
@file{trunk/Identity/Images/Themes} directory structure, the required
d8d967
design models are taken from @file{trunk/Identity/Models/Themes}
513258
directory structure and the action itself is controlled by the
513258
@code{render} functionality of @command{centos-art.sh} script.
74c0c0
74c0c0
In addition to theme rendition you can find @emph{direct rendition},
513258
too. Direct rendition is another way of image production where there
513258
is no artistic motif at all but design models only. Direct rendition
f67de1
is very useful to produce simple content that doesn't need specific
f67de1
background information. Some of these contents are brands, icons and
f67de1
illustrations.  Direct rendition is performed in
513258
@file{trunk/Identity/Images}, the required design models are taken
513258
from @file{trunk/Identity/Models} directory structure and the action
513258
itself is controlled by the @code{render} functionality of
513258
@command{centos-art.sh} script.
513258
513258
@xref{Directories trunk Identity}, for more information about The
513258
CentOS Corporate Identity and how graphic design fits on it.
798844
0c08ea
@subsubsection Documentation
41622d
@cindex Documentation work line
2b93ca
74c0c0
The documentation work line exists to describe what each directory
513258
inside the CentOS Artwork Repository is for, the conceptual ideas
513258
behind them and, if possible, how automation scripts make use of them.
74c0c0
74c0c0
The CentOS Artwork Repository documentation is supported by Texinfo, a
74c0c0
documentation system that uses a single source file to produce both
513258
online information and printed output. 
513258
513258
The repository documentation is organized under @file{trunk/Manual}
e09f1f
directory and uses the repository directory structre as reference.
e09f1f
Each directory in the repository has a documentation entry associated
e09f1f
in the documentation manual.  Documentation entries are stored under
e09f1f
@file{trunk/Manual/Directories} directory and the action itself is
e09f1f
controlled by the @code{help} functionality of @command{centos-art.sh}
e09f1f
script.  
513258
513258
The @code{help} functionality let you create, edit and delete
513258
documentation entries in a way that you don't need to take care of
74c0c0
updating menus, nodes and cross reference information inside the
74c0c0
manual structure; the functionality takes care of it for you.
74c0c0
However, if you need to write repository documentation that have
74c0c0
nothing to do with repository directories (e.g., Preface, Introduction
74c0c0
and similar) you need to do it manually, there is no functionality to
74c0c0
automate such process yet.
87b230
87b230
@xref{Directories trunk Manual}, for more information on
87b230
documentation.
2b93ca
0c08ea
@subsubsection Localization
41622d
@cindex Localization work line
87b0e4
74c0c0
The localization work line exists to provide the translation messages
513258
required to produce content in different languages. Translation
513258
messages inside the repository are stored as portable objects (e.g.,
513258
.po, .pot) and machine objects (.mo) under @file{trunk/Locales}
513258
directory structure.
87b0e4
74c0c0
The procedure used to localize content is taken from @command{gettext}
513258
standard specification.  Basically, translatable strings are retrived
f67de1
from source files in order to create portable objects and machine
f67de1
objects for them.  These portable objects are editable files that
f67de1
contain the information used by translators to localize the
f67de1
translatable strings retrived from source files. On the other hand,
f67de1
machine objects are produced to be machine-redable only, as its name
f67de1
implies, and are produced from portable objects.
87b0e4
87b0e4
Since @command{gettext} needs to extract translatable strings form
513258
source files in order to let translators to localize them, we are
513258
limitted to use source files supported by @command{gettext} program.
513258
This is not a limitation at all since @command{gettext} supports most
513258
popular programming laguages (e.g., C, C++, Java, Bash, Python, Perl,
f67de1
PHP and GNU Awk just to mention a few ones). Nevertheless, formats
f67de1
like SVG, XHTML and Docbook don't figure as supported formats in the
f67de1
list of @command{gettext} supported source files.
87b230
87b230
To translate XML based source files like SVG, XHTML and Docbook we use
513258
the @command{xml2po} program instead. The @command{xml2po} comes with
513258
the @file{gnome-doc-utils} package and retrives translatable strings
f67de1
from one XML file to produce portable objects for them. 
f67de1
f67de1
@quotation
f67de1
@strong{Note}
f67de1
Portable objects produced by @command{xml2po} have the same format
f67de1
that portable objects produced by @command{gettext}. This make the
f67de1
localization process quite consistent from translators' point of view.
f67de1
No matter what the source file be, the translator will always face the
f67de1
same translation file format (i.e., the portable object format).
f67de1
@end quotation
f67de1
f67de1
With the portable object in place, the @command{xml2po} program is
f67de1
used again to create the final translated XML, just with the same
f67de1
definition of the source file where translatable strings were taken
f67de1
from (e.g., if we extract translatable strings from a SVG file, as
f67de1
result we get the same SVG file but with translatable strings already
f67de1
localized ---obviously, for this to happen translators need to
f67de1
localize translatable strings inside the portable object first,
f67de1
localization won't appear as art of magic---).  When using
f67de1
@command{xml2po}, the machine object is used as temporal file to
f67de1
produce the final translated XML file.
87b0e4
87b0e4
@quotation
87b0e4
@strong{Tip} If you want to have your content localized inside CentOS
74c0c0
Artwork Repository be sure to use source files supported either by
74c0c0
@command{gettext} or @command{xml2po} programs.
87b0e4
@end quotation
87b0e4
8e4e50
@xref{Directories trunk Locales}, for more information.
87b0e4
0c08ea
@subsubsection Automation
41622d
@cindex Automation work line
2b93ca
513258
The automation work line exists to standardize content production in
513258
CentOS Artwork Repository. There is no need to type several tasks,
f67de1
time after time, if they can be programmed into just one executable
f67de1
script.
87b0e4
32f4f2
The automation work line takes place under @file{trunk/Scripts}
74c0c0
directory structure. Here is developed the @command{centos-art.sh}
87b0e4
script, a bash script specially designed to automate most frequent
513258
tasks (e.g., rendition, documentation and localization) inside the
513258
repository.  Basically, the @command{centos-art.sh} script is divided
513258
in several functionalities independent one another that perform
f67de1
specific tasks and relay on repository organization to work as
513258
expected.
74c0c0
74c0c0
@quotation
74c0c0
@strong{Tip} If you need to improve the way content is produced, look
32f4f2
inside automation scripts and make your improvement there for everyone
32f4f2
to benefit.
87b0e4
@end quotation
87b0e4
c2929c
@xref{Directories trunk Scripts}, for more information on automation.
8e4e50
0c08ea
@subsection Connection between directories
41622d
@cindex Connection between directories
41622d
@cindex Master paths
41622d
@cindex Auxiliar paths
87b230
513258
In order to produce content in CentOS Artwork Repository, it is
513258
required that all work lines be connected somehow.  This is the way
513258
automation scripts can know where to retrive the information they need
513258
to work with (e.g., design model, translation messages, output
513258
location, etc.).  We build this kind of connection using two path
513258
constructions named @emph{master paths} and @emph{auxiliar paths}.
32f4f2
513258
The master path points only to directories that contain the source
513258
files (e.g., SVG files) required to produce base content (e.g., PNG
513258
files) through automation scripts.  Each master path inside the
513258
repository may have several auxiliar paths associated, but auxiliar
513258
paths can only have one master path associated.
32f4f2
32f4f2
The auxiliar paths can point either to directories or files. When an
32f4f2
auxiliar path points to a directory, that directory contains
513258
information that modifies somehow the content produced from master
f67de1
paths (e.g., translation messages) or provides the output information
f67de1
required to know where to store the content produced from master path.
f67de1
When an auxiliar path points to a file, that file has no other purpose
f67de1
but to document the master path it refers to.
f67de1
f67de1
The relation between auxiliar paths and master paths is realized
f67de1
combining two path informations which are: the master path itself and
f67de1
one second level directory structure from the repository.  Generally,
f67de1
the master path is considered the path identifier and the second level
f67de1
directory structure taken from the repository is considered the common
f67de1
part of the path where the identifier is appended. 
f67de1
f67de1
@float Figure, Path construction
32f4f2
@verbatim
513258
-----+---------------+----------------------------+------+-----------
513258
Path | Suffix        | Identifier                 |Prefix| Type 
513258
-----+---------------+----------------------------+------+-----------
513258
  A  |               |trunk/Identity/Models/Brands|      | Directory 
513258
-----+---------------+----------------------------+------+-----------
513258
  B  |  trunk/Manual/|trunk/Identity/Models/Brands|.texi | File      
513258
-----+---------------+----------------------------+------+-----------
513258
  C  | trunk/Locales/|trunk/Identity/Models/Brands|      | Directory 
513258
-----+---------------+----------------------------+------+-----------
513258
  D  |               |trunk/Identity/Images/Brands|      | Directory 
513258
-----+---------------+----------------------------+------+-----------
513258
  E  | trunk/Locales/|trunk/Identity/Images/Brands|.texi | File      
513258
-----+---------------+----------------------------+------+-----------
513258
f67de1
  A = Master path.
f67de1
  B = Auxiliar path to documentation entry.
f67de1
  C = Auxiliar path to translation messages.
f67de1
  D = Auxiliar path to final content output.
f67de1
  E = Auxiliar path to documentation entry.
32f4f2
@end verbatim
f67de1
@caption{Path construction.}
513258
@end float
513258
f67de1
The path information described above (@pxref{Path construction}) is
f67de1
used by direct rendition and can be taken as reference to add other
f67de1
components that are equally produced in the repository.  To add new
513258
components that make use of direct rendition inside the repository,
513258
change just the component name used above (e.g., @file{Brands}) to
f67de1
that one you want to add, without changing the path structure around
f67de1
it.
f67de1
f67de1
The file organization used by theme rendition extends direct rendition
f67de1
by separating design models information from backgrounds information.
f67de1
To better understand this configuration, you can consider it as two
f67de1
independent lists, one of design models and one of artistic motifs,
f67de1
which are arbitrary combined between themselves in order to render
f67de1
images in specific ways. The possibilities of this configuration are
f67de1
endless and let us describe visual manifestations very well.  For
f67de1
example, consider the organization used to produce @file{Anaconda}
f67de1
images; for CentOS distribution major release 5; using @file{Default}
f67de1
design models and version @file{3} of @file{Flame} artistic motif:
f67de1
f67de1
@float Figure, Path construction extended
32f4f2
@verbatim
513258
-----+---------------+------------------------------------------------------+------+-----------
513258
Path | Suffix        | Identifier                                           |Prefix| Type 
513258
-----+---------------+------------------------------------------------------+------+-----------
d8d967
  A  |               |trunk/Identity/Models/Themes/Default/Distro/5/Anaconda|      | Directory 
513258
-----+---------------+------------------------------------------------------+------+-----------
d8d967
  B  |  trunk/Manual/|trunk/Identity/Models/Themes/Default/Distro/5/Anaconda|.texi | File      
513258
-----+---------------+------------------------------------------------------+------+-----------
d8d967
  C  | trunk/Locales/|trunk/Identity/Models/Themes/Default/Distro/5/Anaconda|      | Directory 
513258
-----+---------------+------------------------------------------------------+------+-----------
d8d967
  D  |               |trunk/Identity/Images/Themes/Flame/3/Distro/5/Anaconda|      | Directory 
513258
-----+---------------+------------------------------------------------------+------+-----------
d8d967
  E  | trunk/Locales/|trunk/Identity/Images/Themes/Flame/3/Distro/5/Anaconda|.texi | File      
513258
-----+---------------+------------------------------------------------------+------+-----------
513258
f67de1
  A = Master path.
f67de1
  B = Auxiliar path to documentation entry.
f67de1
  C = Auxiliar path to translation messages.
f67de1
  D = Auxiliar path to final content output.
f67de1
  E = Auxiliar path to documentation entry.
32f4f2
@end verbatim
f67de1
@caption{Path construction extended.}
513258
@end float
87b230
f67de1
The path information described above (@pxref{Path construction
f67de1
extended}) is used by theme rendition and can be taken as reference to
f67de1
add other components that are equally produced in the repository.
87b230
f67de1
In this configuration we can change both design model name (e.g.,
f67de1
@file{Default}) and artistic motif name (e.g., @file{Flame/3}) to
f67de1
something else in order to achieve a different result. The only
f67de1
limitations impossed are the storage space provided in the server
f67de1
machine and your own creativeness as graphic designer.
f67de1
f67de1
@quotation
f67de1
@strong{Note}
f67de1
A theme ready for implementation may consume from 100 MB to 400 MB of
f67de1
storage space. The exact space consumed by a theme depends on the
f67de1
amount of screen resolutions the theme supports. The more screen
f67de1
resolutions the theme supports, the more storage space demanded for
f67de1
it.
f67de1
@end quotation
f67de1
f67de1
In this configuration we saw how to build the path information for
f67de1
@file{Anaconda} component as part of CentOS Distribution visual
f67de1
manifestation, but that is not the only component we have inside
f67de1
CentOS Distribution visual manifestation.  There are other components
f67de1
like Syslinux, Grub, Rhgb, Gdm, Kdm, Gsplash and Ksplash that share a
f67de1
similar file organization to that described above for @file{Anaconda}
f67de1
component.
87b0e4
0c08ea
@subsection Syncronizing path information
41622d
@cindex Syncronizing path information
87b0e4
f67de1
Syncronizing path information is the action that keeps all path
513258
information up to date in the repository. This action implies both
513258
@emph{file movement} and @emph{file content replacement} in this very
f67de1
specific order. File movement is related to duplicate, delete and
f67de1
rename files and directories in the repository.  File content
f67de1
replacement is related to replace information, path information in
f67de1
this case, inside files in the repository.
513258
513258
The order followed to syncronize path information is relevant because
f67de1
the versioned nature of the files we are working with. We don't
f67de1
perform file content replacement first because that would imply a
f67de1
repository change which will immediatly demmand a commit in order for
f67de1
actions like duplicate, delete or rename to take place. However, if we
f67de1
perform file movement first, it is possible to commit both file moved
f67de1
and file content replacements as if they were just one change. In this
513258
case the file content replacement takes palce in the target location
f67de1
that have been duplicated or renamed, not the one use as source
f67de1
location. This configuration is specially useful when files are
f67de1
renamed (i.e., one file is copied from a source location to a target
f67de1
location and then the source location of it is removed from
f67de1
repository).
87b0e4
87b0e4
@quotation
513258
@strong{Warning} There is no support for URLs actions inside
513258
@command{centos-art.sh} script.  The @command{centos-art.sh} script is
513258
designed to work with local files inside the working copy only. If you
513258
need to perform URL actions directly, use Subversion commands instead.
87b0e4
@end quotation
87b0e4
f67de1
When one master path is changed it is required that all related
f67de1
auxiliar paths be changed, too. This is required in order for master
f67de1
paths to retain their relation with auxiliar paths.  This way,
f67de1
automation scripts are able to know where to retrive translation
f67de1
messages from, where to store final output images to and where to look
f67de1
for documentation. If relation between master paths and auxiliar paths
f67de1
is lost, there is no way for automation scripts to know where to
f67de1
retrive the information they need.
f67de1
f67de1
The auxiliar paths should never be modified under any reason but to
f67de1
satisfy the relationship with the master path.  Liberal change of
f67de1
auxiliar paths may suppress the conceptual idea they were initially
f67de1
created for; and certainly, automation scripts may stop working as
f67de1
expected. The update direction to rename path information must be from
f67de1
master path to auxiliar path and never the opposite.
f67de1
f67de1
The relation between master and auxiliar paths is useful to keep
f67de1
repository organized but introduce some complications when we work
f67de1
with files that use master path information as reference to build
f67de1
structural information.  This is the case of repository documentation
f67de1
manual source files where inclusions, menus, nodes and cross
f67de1
references are built using master path information as reference.  Now,
f67de1
to see what kind of complication we are talking about, consider what
f67de1
would happen to a structural definitions (i.e., inlusions, menus,
f67de1
nodes and cross refereces) already set in the manual from one master
f67de1
path that is suddenly renamed to something different.  If the path
f67de1
information is not syncronized, at this point, we lose connection
f67de1
between the master path and the auxiliar path created to store the
f67de1
related documentation entry, as well as the related structural
f67de1
definitions that end up pointing to a master path that no longer
f67de1
exist.
f67de1
f67de1
The syncronization of path information is aimed to solve these kind of
f67de1
issues.
f67de1
0c08ea
@subsection Extending repository organization
41622d
@cindex Extending repository organization
87b0e4
513258
Occasionly, you may find that new components of The CentOS Project
513258
Corporate Identity need to be added to the repository in order to work
513258
them out. If that is the case, the first question we need to ask
513258
ourselves, before start to create directories blindly all over, is:
513258
@emph{What is the right place to store it?}
87b0e4
87b230
The best place to find answers is in The CentOS Community (see page
87b230
@url{http://wiki.centos.org/GettingHelp}), but going there with hands
87b230
empty is not good idea. It may give the impression you don't really
87b230
care about. Instead, consider the following suggestions to find your
87b230
own comprehension in order to make your own propositions based on it.
87b230
513258
When extending respository structure it is very useful to bear in mind
513258
The CentOS Project Corporate Identity Structure (@pxref{Directories
513258
trunk Identity}) The CentOS Mission and The CentOS Release Schema. The
513258
rest is just matter of choosing appropriate names. It is also worth to
513258
know that each directory in the repository responds to a conceptual
513258
idea that justifies its existence.
513258
513258
To build a directory structure, you need to define the conceptual idea
513258
first and later create the directory. There are some locations inside
513258
the repository that already define some concepts you probably want to
d8d967
reuse. For example, @file{trunk/Identity/Images/Themes} to store theme
d8d967
artistic motifs, @file{trunk/Identity/Models/Themes} to store theme
513258
design models, @file{trunk/Manual} to store documentation files,
513258
@file{trunk/Locales} to store translation messages,
513258
@file{trunk/Scripts} to store automation scripts and so on.
87b230
87b230
To illustrate this desition process let's consider the
d8d967
@file{trunk/Identity/Images/Themes/TreeFlower/3} directory structure
513258
as example.  This directory can be read as: the theme development line
513258
of version @file{3} of @file{TreeFlower} artistic motif. Additional,
513258
we can identify that artistic motifs are part of themes as well as
513258
themes are part of The CentOS Project Corporate Identity. These
513258
concepts are better described independently in each documentation
513258
entry related to the directory structure as it is respectively shown
513258
in the list of commands bellow.
87b0e4
87b0e4
@verbatim
74c0c0
centos-art help --read turnk
74c0c0
centos-art help --read turnk/Identity
74c0c0
centos-art help --read turnk/Identity/Themes
d8d967
centos-art help --read turnk/Identity/Images/Themes
d8d967
centos-art help --read turnk/Identity/Images/Themes/TreeFlower
d8d967
centos-art help --read turnk/Identity/Images/Themes/TreeFlower/3
87b0e4
@end verbatim
87b0e4
513258
The concepts behind other location can be found in the same way
513258
described above, just change the path information used above to the
87b230
one you are trying to know concepts for.