<chapter id="intro-repoconvs">
<title>Repository Convenctions</title>
<para>
&TCAR; is supported by <ulink
url="http://subversion.tigris.org/">Subversion</ulink>, 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.
</para>
<para>
When using Subversion there is one <quote>source
repository</quote> and many <quote>working copies</quote> 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.
</para>
<sect1 id="repo-usage-policy">
<title>Policy</title>
<para>
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 &TCDML;.
Generally, people download working copies from &TCAR;,
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 &TCAR; for others to benefit
from them.
</para>
<para>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 <emphasis>good cooperating citizen</emphasis>.
Otherwise, your rights to commit changes might be temporarly
revoked or permanently banished.</para>
<para>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.</para>
<para>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 the CentOS Artwork Repository to accomplish
its mission which is: to provide a colaborative tool for &TCC;
where &TCP; corporate visual identity is built and maintained
by &TCC; itself.</para>
<para>It is also important to remember that all the program
and documentation source files inside CentOS Artwork
Repository must comply the terms of <xref
linkend="licenses-gpl" /> and <xref linkend="licenses-gfdl" />
respectively in order for them to remain inside the
repository.</para>
</sect1>
<sect1 id="intro-usage-worklines">
<title>Work Lines</title>
<para>Content production inside the repository is organized by
<emphasis>work lines</emphasis>. There are three major work
lines of production inside The CentOS Artwork Repository,
which are: <emphasis>Graphic design</emphasis>,
<emphasis>Documentation</emphasis> and
<emphasis>Localization</emphasis>. The specific way of
producing content inside each specific work line is
standardized by mean of <command>centos-art.sh</command>
script (which in turn, can be considered a work line by itself
[e.g., the <emphasis>Automation</emphasis> work line]). The
<command>centos-art.sh</command> script provides one specific
functionality for automating each major work line of content
production (e.g., <code>render</code> for producing images,
<code>help</code> for manage documentation, and
<code>locale</code> for localizing contents).</para>
<para>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 <filename
class="directory">trunk/Identity</filename> directory.</para>
<para>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 <filename
class="directory">trunk/Manuals</filename> directory.</para>
<para>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
<filename class="directory">trunk/Locales</filename>
directory.</para>
<para>The automation work line exists to standardize content
production inside the working copies of CentOS Artwork
Repository. Here is developed the
<command>centos-art.sh</command> 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
<filename class="directory">trunk/Scripts</filename>
directory.</para>
</sect1>
<sect1 id="intro-usage-conbdirs">
<title>Relation Between Directories</title>
<para>In order for automation scripts to produce content inside a
working copy of CentOS Artwork Repository, it is required that all
work lines be related somehow. The relation is used by automation
scripts to know where to retrive the information they need to work
with (e.g., design model, translation messages, output locations,
etc.). This kind of relation is built using two path
constructions named <emphasis>master paths</emphasis> and
<emphasis>auxiliar paths</emphasis>.</para>
<para>The master path points only to directories that contain
source files (e.g., SVG files) required to produce output 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.</para>
<para>Master paths used for producing images through SVG rendition
are organized under <filename
class="directory">trunk/Identity/Models</filename> directory
structure and the auxiliar paths under <filename
class="directory">trunk/Identity/Images</filename>, <filename
class="directory">trunk/Locales</filename> and <filename
class="directory">trunk/Manuals</filename> directory
structures.</para>
<para>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 the content produced
from the master path should be stored. When an auxiliar path
points to a file, that file has no other purpose but to document
the master path it refers to.</para>
<para>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.</para>
<para>The relationship between auxiliar paths and master paths is
built by combining the master path and the second level directory
structures of the repository. The master path is considered the
path identifier and the repository second level directory
structure is considered the common part of the path where the path
identifier is appended to. So, if we have the master path
<filename
class="directory">trunk/Identity/Models/Brands</filename>, we'll
end up having, at least, the <filename
class="directory">trunk/Identity/Images/Brands</filename> auxiliar
path for storing output files and, optionally, one path under
<filename class="directory">trunk/Manuals</filename> for storing
documentation and one path under <filename
class="directory">trunk/Locales</filename> for storing
localizations.</para>
</sect1>
<sect1 id="intro-usage-syncro">
<title>Syncronizing Paths</title>
<para>Once both master paths and their auxiliar paths have been
set, they shouldn't be changed. Assuming one master path must be
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 process of keeping relation
between master paths and auxiliar paths is known as <emphasis>path
syncronization</emphasis>. </para>
<para>Path syncronization is required for automation scripts to
know where to store final output, where to retrive translation
messages, documentation, and any information that might be
desired. If the relation between master paths and auxiliar paths
is lost, there is no way for <command>centos-art.sh</command>
script to know where to retrive the information it needs to work
with. Path syncronization is the way we use to organize and
extend the information stored in the repository.</para>
<para>Path syncronization may imply 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.</para>
<para>The order followed to syncronize path information is very
important because the versioned nature of the repository files we
are working with. When a renaming action must be performed, we
avoid making replacements inside files first and file movements
later. This would require two commit actions: one for the files'
internal changes and another for the file movement itself.
Otherwise, we prefer to perform file movements first and file
internal replacements later. This way it is possible to commit
both changes as if they were just one.</para>
<warning><para>There is no support for URLs actions inside
<command>centos-art.sh</command> script. The
<command>centos-art.sh</command> script is designed to work with
local files inside the working copy only. If you need to perform
URL actions directly, use Subversion commands
instead.</para></warning>
<para>At this moment there is no full implementation of path
syncronization process inside <command>centos-art.sh</command>
script except by <quote>texinfo</quote> backend of
<code>help</code> functionality which provides a restricted
implementation of path syncronization to this specific area of
documentation through the <option>--copy</option>,
<option>--delete</option> and <option>--rename</option> options.
The plan for a full implementation of path syncronization would be
to create individual restricted implementations like this one for
other areas that demand it and then, create a higher implmentation
that combines all restricted implementations as needed. This way,
if we try to rename a repository directory the higer action will
define which are all the restricted actions that should be
performed in order for make a full path syncronization. For
example, if the directory we are renaming is part of graphic
design work line, it is required to syncronize related paths in
documentation and localization work lines. Likewise, if the
directory we are renaming is in documentation work line, it is
required to syncronize related paths in graphic design and
localization work lines. In all these cases, the direction used
for syncronizing paths must be from master path to auxiliar path
and never the opposite (i.e., rename the master path first and
auxiliar paths later).</para>
<para>A practical example, through which you can notice the
usefulness of path syncronization process, is what happen when
documentation entries are renamed (see section ...).</para>
</sect1>
<sect1 id="intro-usage-extending">
<title>Extending Repository Organization</title>
<para>Occasionly, you may find that new components of The
CentOS Project corporate visual 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: <emphasis>What is the
right place to store it?</emphasis></para>
<para>The best place to find answers is in The CentOS
Community (see page http://wiki.centos.org/Help), 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.</para>
<para>When extending respository structure it is very useful
to bear in mind The CentOS Project corporate visual identity
structure, The CentOS Mission and The CentOS Release Schema.
The rest is a 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.</para>
<para>To build a directory structure inside the repository,
you need to define the conceptual idea first and later create
the directory, remembering that there are locations inside the
repository that define conceptual ideas you probably would
prefer to reuse. For example, the <filename
class="directory">trunk/Identity/Images/Themes</filename>
directory stores theme artistic motifs, the <filename
class="directory">trunk/Identity/Models/Themes</filename>
directory stores theme design models, the <filename
class="directory">trunk/Manuals</filename> directory stores
documentation files, the <filename
class="directory">trunk/Locales</filename> stores translation
messages, and the <filename
class="directory">trunk/Scripts</filename> stores automation
scripts.</para>
<para>
To better illustrate this desition process, you can
consider to examin the <filename
class="directory">trunk/Identity/Images/Themes/TreeFlower/3</filename>
directory structure as example. This directory can be
read as: the theme development line of version
<quote>3</quote> of <quote>TreeFlower</quote> artistic
motif. Additional, we can say that
<quote>TreeFlower</quote> artistic motif is part of
themes, as themes are part of The CentOS Project corporate
visual identity.
</para>
<para>
The relationship between conceptual ideas can be
stablished by reading each repository documentation entry
individually, from <filename
class="directory">trunk</filename> directory to a deeper
directory in the path. For reading repository
documentation entries we use the <code>help</code>
functionality of <command>centos-art.sh</command> script.
</para>
</sect1>
<sect1 id="intro-usage-filenames">
<title>File Names</title>
<para>Inside the CentOS Artwork Repository, generally, file
names are all written in lowercase (e.g.,
<filename>01-welcome.png</filename>,
<filename>splash.png</filename>,
<filename>anaconda_header.png</filename>, etc.) and directory
names are all written capitalized (e.g., <filename
role="directory">Identity</filename>, <filename
role="directory">Themes</filename>, <filename
role="directory">Motifs</filename>) and sometimes in cammel
case (e.g., <filename role="directory">TreeFlower</filename>,
etc.). </para>
<para>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.</para>
</sect1>
<sect1 id="intro-usage-layout">
<title>Layout</title>
<para>The CentOS Artwork Repository is organized through a
convenctional <quote>trunk</quote>, <quote>branches</quote>
and <quote>tags</quote> layout. Explanation of each directory
inside the repository can be found in the Directories
part.</para>
</sect1>
</chapter>