<?xml version="1.0"?>
<sect1 id="repository-usage-section-6" xreflabel="Syncronizing path information" label="3.6">

    <title>Syncronizing path information</title>

    <para>Syncronizing path information is the action that keeps all
    path information up to date in the repository. This action implies
    both @emph{file movement} and @emph{file content replacement} in
    this very specific order. File movement is related to duplicate,
    delete and rename files and directories in the repository.  File
    content replacement is related to replace information, path
    information in this case, inside files in the repository.</para>
    
    <para>The order followed to syncronize path information is
    relevant because the versioned nature of the files we are working
    with. We don't perform file content replacement first because that
    would imply a repository change which will immediatly demmand a
    commit in order for actions like duplicate, delete or rename to
    take place. However, if we perform file movement first, it is
    possible to commit both file moved and file content replacements
    as if they were just one change. In this case the file content
    replacement takes palce in the target location that have been
    duplicated or renamed, not the one use as source location. This
    configuration is specially useful when files are renamed (i.e.,
    one file is copied from a source location to a target location and
    then the source location of it is removed from repository).</para>
    
    <warning><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 commands
    instead.</para></warning>
    
    <para>When one master path is changed it is required that all
    related auxiliar paths be changed, too. This is required in order
    for master paths to retain their relation with auxiliar paths.
    This way, automation scripts are able to know where to retrive
    translation messages from, where to store final output images to
    and where to look for documentation. If 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.</para>
    
    <para>The auxiliar paths should never be modified under any reason
    but to satisfy the relationship with the master path.  Liberal
    change of auxiliar paths may suppress the conceptual idea they
    were initially created for; and certainly, automation scripts may
    stop working as expected. The update direction to rename path
    information must be from master path to auxiliar path and never
    the opposite.</para>
    
    <para>The relation between master and auxiliar paths is useful to
    keep repository organized but introduce some complications when we
    work with files that use master path information as reference to
    build structural information.  This is the case of repository
    documentation manual source files where inclusions, menus, nodes
    and cross references are built using master path information as
    reference.  Now, to see what kind of complication we are talking
    about, consider what would happen to a structural definitions
    (i.e., inlusions, menus, nodes and cross refereces) already set in
    the manual from one master path that is suddenly renamed to
    something different.  If the path information is not syncronized,
    at this point, we lose connection between the master path and the
    auxiliar path created to store the related documentation entry, as
    well as the related structural definitions that end up pointing to
    a master path that no longer exist.</para>
    
    <para>The syncronization of path information is aimed to solve
    these kind of issues.</para>
    
</sect1>