<section id="repo-convs-syncpaths">

    <title>Syncronizing Repository Paths</title>

    <para>  
        Once both master and auxiliar paths have been related in the
        repository, they shouldn't be changed except you absolutly
        need to do so. In this cases, when you need to change master
        or auxiliar paths, it is required that you also change the
        relation between them so as to retain their bond.  This
        process of keeping master and auxiliar paths
        <quote>connected</quote> between themselves 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 from, and whatever information you might need to
        count with. If the relation between master paths and auxiliar
        paths is lost, there is no way for automation scripts to know
        where to retrive the information they need to work with or
        where to store the output information produced from it.
        Through path syncronization we organize and extend the content
        production inside the repository.
    </para>
    
    <para>
        Path syncronization affects 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 after a file has been
        moved.
    </para>

    <para>
        The order followed to syncronize path information is very
        important because the versioned nature of the files we are
        working with. When a renaming action needs to be performed
        inside the repository, we avoid making replacements inside
        files first and file movements later. This would demand two
        commit actions: one for the files' internal changes and
        another for the file movement itself.  Instead, we prefer to
        perform file movements first and files' internal replacements
        later.  This way it is possible to commit both changes as if
        they were just one.
    </para>
 
    <note>
    <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's commands
        instead.
    </para>
    </note>

    <para>
        At this moment there isn't full implementation of path
        syncronization inside <command>centos-art.sh</command> script
        and that is somthing we need to do oursleves. However, the
        <quote>texinfo</quote> backend inside the
        <function>help</function> functionality does provide a restricted
        implementation of path syncronization to documentation area
        through the <option>--copy</option>, <option>--delete</option>
        and <option>--rename</option> options. You can read this
        implementation and use it as reference to implement path
        syncronization in other areas.
    </para>
        
    <para>
        The plan for a full implementation of path syncronization
        inside <command>centos-art.sh</command> script would be to
        create individual restricted implementations like the one in
        <quote>texinfo</quote> backend for other areas that demand it
        and then, create a higher implmentation that combines them all
        as needed. This way, if we try to rename a repository
        directory, the higher action can know which are all the
        restricted actions that should be performed in order
        to make the full path syncronization.
    </para>
        
    <para>
        For example, if the directory we are renaming is a master
        path, it is required to syncronize the related output and
        localization auxiliar paths. On the other hand, if the
        directory we are renaming through full path syncronization is
        an auxiliar path, it is required to determine first what is
        the related master path and later, perform the syncronization
        from master path to auxiliar paths as if the path provided
        would be the master path not the auxiliar path.
    </para>

</section>