GNU shar utilities: 4. Remote synchronisation of directories

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

# 4. Remote synchronisation of directories

For using the `remsync` facility, besides `sharutils` of course, you also need `perl`, GNU `tar`, GNU `findutils` and `gzip`, all installed. You also need a `sum` program which is BSD-compatible, for example the one from GNU `textutils`.

The `remsync` program tries to maintain up-to-date copies of whole hierarchy of files over many loosely connected sites, provided there is at least some slow electronic mail between them. It prepares and sends out specially packaged files called synchronization packages, and is able to processes them after reception.

There is no master site, each site has an equal opportunity to modify files, and modified files are propagated. Among many other commands, the `broadcast` command prepares and sends a synchronization package from the current site to all others, while the `process` command is used to apply synchronization packages locally after reception from remote sites. `remsync` will never send a file to another site without being asked to with the `broadcast` command, and besides the project synchronization state files (always named ``.remsync'`), it will never modify a file locally without being asked to with the `process` command.

The unit of transmission is a file, whatever its size may be. Nothing less than whole files are being transmitted. People deciding to cooperate in keeping a synchronized set of files must have trust each other, as each participant has the power of modifying the contents of files at other sites. When `remsync` is used by a single individual travelling between many sites, as it is often the case, this confidence problem should be easier to resolve :-).

The `process` command will modify a file without asking confirmation, as long as there is no reason to believe that the file has been modified at more than one place. When some confusion arises from the fact many people independently modified a single file, the receiving user of conflicting files will have the duty of resolving them into a merged version. So, the merging has to be done at the site where the discrepancy is observed, from where it is propagated again to others participants. There is no locking mechanism, so people should use other means, like electronic mail, for telling each other what they do, and which part of a project they are working on.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

This document was generated by Bruce Korb on July, 24 2005 using texi2html 1.76.