| <sect1 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. Path |
| syncronization is the way we use through to organize and |
| extend the information stored in the repository. |
| </para> |
| |
| <para> |
| Path syncronization involves 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 movement. |
| </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. Otherwise, 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 is no full implementation of path |
| syncronization process inside <command>centos-art.sh</command> |
| script and it is somthing we need to do oursleves. However, |
| the <quote>texinfo</quote> backend of <code>help</code> |
| functionality which provides a restricted implementation of |
| path syncronization to this specific area of documentation |
| through the <option>--copy</option>, <option>--delete</option> |
| and <option>--rename</option> options you can take as |
| reference to implement it in other areas. |
| </para> |
| |
| <para> |
| The plan for a full implementation of path syncronization |
| 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 will define 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> |
| |
| </sect1> |