<sect1>
    <title>2012's</title>

    <para>
        &TCAR; development was eventually stopped at November 2011
        until July 2012 when it was decided 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.
    </para>
    
    <para>
        As consequence of this autonomy we want 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. The <xref linkend="repository-history-2012-1" />,
        illustrates 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/  &lt;--| from https://projects.centos.org/svn/artwork/
    |       |   |   `-- es_ES/
    |       |   |       |-- messages.po
    |       |   |       `-- messages.pot
    |       |   `-- Report/
    |       |       `-- es_ES/
    |       |           |-- messages.po
    |       |           `-- messages.pot
    |       `-- es_ES/
    |           |-- LC_MESSAGES/
    |           |   `-- centos-art.sh.mo
    |           |-- centos-art.sh.po
    |           `-- centos-art.sh.pot
    `-- Scripts/            
        `-- Bash/
            |-- Functions/
            |   |-- Render/  &lt;--| from https://projects.centos.org/svn/artwork/
            |   `-- Report/
            `-- myapp.sh
</programlisting>
    </textobject>
    </mediaobject>
    </screenshot>
    </example>

    <para>
        At this point you find yourself working with a mix of two
        different central repositories in the same working copy. One
        repository provides your organization files. The other
        repository provides the files of <function>render</function>
        functionality at &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.
    </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>ispadm.sh</filename> instead of
        <filename>centos-art.sh</filename> so the information we set
        inside it could reflect the specific needs that motiveted 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
        controled 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 of 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>