|
|
054a7b |
<sect1 id="intro-repoconvs-syncpaths">
|
|
|
054a7b |
|
|
|
054a7b |
<title>Syncronizing Paths</title>
|
|
|
054a7b |
|
|
|
054a7b |
<para>
|
|
|
054a7b |
Once both master paths and their auxiliar paths have been set,
|
|
|
054a7b |
they shouldn't be changed. Assuming one master path must be
|
|
|
054a7b |
changed it is required that all related auxiliar paths be
|
|
|
054a7b |
changed, too. This is required in order for master paths to
|
|
|
054a7b |
retain their relation with auxiliar paths. This process of
|
|
|
054a7b |
keeping relation between master paths and auxiliar paths is
|
|
|
054a7b |
known as <emphasis>path syncronization</emphasis>.
|
|
|
054a7b |
</para>
|
|
|
054a7b |
|
|
|
054a7b |
<para>
|
|
|
054a7b |
Path syncronization is required for automation scripts to know
|
|
|
054a7b |
where to store final output, where to retrive translation
|
|
|
054a7b |
messages, documentation, and any information that might be
|
|
|
054a7b |
desired. If the relation between master paths and auxiliar
|
|
|
054a7b |
paths is lost, there is no way for
|
|
|
054a7b |
<command>centos-art.sh</command> script to know where to
|
|
|
054a7b |
retrive the information it needs to work with. Path
|
|
|
054a7b |
syncronization is the way we use to organize and extend the
|
|
|
054a7b |
information stored in the repository.
|
|
|
054a7b |
</para>
|
|
|
054a7b |
|
|
|
054a7b |
<para>
|
|
|
054a7b |
Path syncronization may imply both movement of files and
|
|
|
054a7b |
replacement of content inside files. Movement of files is
|
|
|
054a7b |
related to actions like renaming files and directories inside
|
|
|
054a7b |
the repository. Replacement of content inside files is
|
|
|
054a7b |
related to actions like replacing information (e.g., paths
|
|
|
054a7b |
information) inside files in order to keep file contents and
|
|
|
054a7b |
file locations consistent one another.
|
|
|
054a7b |
</para>
|
|
|
054a7b |
|
|
|
054a7b |
<para>
|
|
|
054a7b |
The order followed to syncronize path information is very
|
|
|
054a7b |
important because the versioned nature of the repository files
|
|
|
054a7b |
we are working with. When a renaming action must be performed,
|
|
|
054a7b |
we avoid making replacements inside files first and file
|
|
|
054a7b |
movements later. This would require two commit actions: one
|
|
|
054a7b |
for the files' internal changes and another for the file
|
|
|
054a7b |
movement itself. Otherwise, we prefer to perform file
|
|
|
054a7b |
movements first and file internal replacements later. This way
|
|
|
054a7b |
it is possible to commit both changes as if they were just
|
|
|
054a7b |
one.
|
|
|
054a7b |
</para>
|
|
|
054a7b |
|
|
|
054a7b |
<warning>
|
|
|
054a7b |
<para>
|
|
|
054a7b |
There is no support for URLs actions inside
|
|
|
054a7b |
<command>centos-art.sh</command> script. The
|
|
|
054a7b |
<command>centos-art.sh</command> script is designed to
|
|
|
054a7b |
work with local files inside the working copy only. If you
|
|
|
054a7b |
need to perform URL actions directly, use Subversion
|
|
|
054a7b |
commands instead.
|
|
|
054a7b |
</para>
|
|
|
054a7b |
</warning>
|
|
|
054a7b |
|
|
|
054a7b |
<para>
|
|
|
054a7b |
At this moment there is no full implementation of path
|
|
|
054a7b |
syncronization process inside <command>centos-art.sh</command>
|
|
|
054a7b |
script except by <quote>texinfo</quote> backend of
|
|
|
054a7b |
help functionality which provides a restricted
|
|
|
054a7b |
implementation of path syncronization to this specific area of
|
|
|
054a7b |
documentation through the <option>--copy</option>,
|
|
|
054a7b |
<option>--delete</option> and <option>--rename</option>
|
|
|
054a7b |
options. The plan for a full implementation of path
|
|
|
054a7b |
syncronization would be to create individual restricted
|
|
|
054a7b |
implementations like this one for other areas that demand it
|
|
|
054a7b |
and then, create a higher implmentation that combines all
|
|
|
054a7b |
restricted implementations as needed. This way, if we try to
|
|
|
054a7b |
rename a repository directory the higer action will define
|
|
|
054a7b |
which are all the restricted actions that should be performed
|
|
|
054a7b |
in order for make a full path syncronization. For example, if
|
|
|
054a7b |
the directory we are renaming is part of graphic design work
|
|
|
054a7b |
line, it is required to syncronize related paths in
|
|
|
054a7b |
documentation and localization work lines. Likewise, if the
|
|
|
054a7b |
directory we are renaming is in documentation work line, it is
|
|
|
054a7b |
required to syncronize related paths in graphic design and
|
|
|
054a7b |
localization work lines. In all these cases, the direction
|
|
|
054a7b |
used for syncronizing paths must be from master path to
|
|
|
054a7b |
auxiliar path and never the opposite (i.e., rename the master
|
|
|
054a7b |
path first and auxiliar paths later).
|
|
|
054a7b |
</para>
|
|
|
054a7b |
|
|
|
054a7b |
<para>
|
|
|
054a7b |
A practical example, through which you can notice the
|
|
|
054a7b |
usefulness of path syncronization process, is what happen when
|
|
|
054a7b |
documentation entries are renamed (see section ...).
|
|
|
054a7b |
</para>
|
|
|
054a7b |
|
|
|
054a7b |
</sect1>
|