| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 June, 3 2006 using texi2html 1.76.