<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>

    <note>

    <para>

        The ideas described here have not been implemented inside

        <command>centos-art.sh</command> script, yet.

    </para>

    </note>

    <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 

        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 &TC;; 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

        &TC;; (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 &TC;;. You probably need to change this if you are

        producing images to a different organization than &TC;;. 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 &TC;;.

    </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>