Blob Blame History Raw
<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 <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/  &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/
    |           |   `-- myapp.sh.mo
    |           |-- myapp.sh.po
    |           `-- myapp.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 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>