<sect1>
<title>2012's</title>
<para>
&TCAR; development was eventually stopped at November 2011
until July 2012 when we needed to make the
<command>centos-art.sh</command> script a bit more
customizable than it presently was. For example, it was
considered as a need that functionalities inside the
<command>centos-art.sh</command> script must be not just
conceived independent one another but reusable in different
contexts as well.
</para>
<para>
As consequence of this autonomy we wanted to have among
functionalities, the procedure used to locale messages inside
the <command>centos-art.sh</command> script had to be modified
in order to accept such pluggable behavior into the script. We
cannot have a single <filename>centos-art.sh.po</filename>
file for all the functionalities because all functionalities
are not used in the same context. Instead, it is required that
each functionality has its own <filename
class="extension">messages.po</filename> file in order to
treat them individually. Otherwise, we would end up having
translations for functionalities that we don't need or use in
our current context.
</para>
<para>
As an example, consider a situation where you are working on
the corporate identity of &TCP; and you need to start a new
corporate identity project for another organization. You want
to keep the directory structure of &TCAR; and its automation
tool, the <command>centos-art.sh</command> script. Your new
project requires you to introduce new functionalities to
<command>centos-art.sh</command> that don't fit the needs of
&TCP; (e.g., you want to introduce a
<function>report</function> functionality to mesure how much
connect time do you consume through your PPP internface.).
</para>
<para>
To solve this issue, you need to mix specific parts of
different central repositories into one single working copy.
This is the working copy you'll use to manage your new
project. In <xref linkend="repository-history-2012-1" />, we
see how the <function>render</function> functionality living
in &TCAR; has been integrated into the working copy of your
new project.
</para>
<example id="repository-history-2012-1">
<title>Mixing automation functionalities.</title>
<screenshot>
<screeninfo>Mixing automation functionalities.</screeninfo>
<mediaobject>
<textobject>
<programlisting>
/home/al/Projects/Myapp/
`-- trunk/
|-- Locales/
| `-- Bash/
| |-- Functions/
| | |-- Render/ <--| from https://projects.centos.org/svn/artwork/
| | | `-- es_ES/
| | | |-- messages.po
| | | `-- messages.pot
| | `-- Report/
| | `-- es_ES/
| | |-- messages.po
| | `-- messages.pot
| `-- es_ES/
| |-- LC_MESSAGES/
| | `-- myapp.sh.mo
| |-- myapp.sh.po
| `-- myapp.sh.pot
`-- Scripts/
`-- Bash/
|-- Functions/
| |-- Render/ <--| from https://projects.centos.org/svn/artwork/
| `-- Report/
`-- myapp.sh
</programlisting>
</textobject>
</mediaobject>
</screenshot>
</example>
<para>
At this point your working copy contains files from two
different central repositories. One repository provides the
files of your new organization project and the other one
provides the files related to the <function>render</function>
functionality from &TCAR;. In this environment, all updates
commited to the <function>render</function> functionality at
&TCAR; will be available to you too, the next time you update
your working copy. Likewise, if you change something in the
<function>render</function> functionality and commit your
changes, your changes will be available to poeple working in
&TCAR; the next time they update their working copies.
</para>
<para>
Understanding the need of mixing different repositories into a
single working copy is an important setp for reusing the
functionalities that come with centos-art.sh script, but it is
not enough if you want to customize the information produced
by it. By default, the centos-art.sh script uses information
related to &TCP;. You probably need to change this if you are
producing images to a different organization than &TCP;. For
example, some of the information you might need to change
would be the copyright holder, brands, domain names, mailing
lists, and so forth. To change this information you need to
duplicate the file <filename>centos-art.sh</filename> and
rename it to something else. Later, you need to edit the
renamed version and change variables inside according your
needs. In <xref linkend="repository-history-2012-1" />, we
used the name <filename>myapp.sh</filename> instead of
<filename>centos-art.sh</filename> so the information we set
inside it could reflect the specific needs that motivated the
creation of a new project without affecting those from &TCP;.
</para>
<para>
Most of the information you need to change in your duplicated
version of <filename>centos-art.sh</filename> file is
controlled by a set of read-only variables. You modify these
variables here and they will be available all along the script
execution time. For example, you can change the value of
<varname>CLI_WRKCOPY</varname> variable inside your duplicated
version of <filename>centos-art.sh</filename> to change the
absolute path you use to store your working copy.
</para>
<caution>
<para>
Setting the absolute path of your working copy to
something different than
<filename>/home/centos/Projects/artwork</filename> will
provoke that some components inside &TCAR; be processed
correctly while others don't.
</para>
<para>
For example, SVG design models will be processed correctly
but CSS files won't. This is because before processing
SVG files we expand translation markers inside them create
a temporal file and then process the temporal file instead
of the original SVG file. In the case of CSS files doing
the same isn't appropriate.
</para>
</caution>
</sect1>