Copyright (C) 1994 Free Software Foundation, Inc.
Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.
Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.
Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Foundation.
remsync and friends
The remsync program allows for transmitting, over email, selected
parts of directories for trying to maintain up-to-date files over many
sites. It sends out and processes incoming specially packaged files
using shar, tar, gzip and electronic mail programs.
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 sends an update package from the
current site to all others, the process command is used to apply
update packages locally after reception from remote sites.
The unit of transmission is whole files. For now, whenever a module is modified, it is silently synchronized only if it has been modified at only one place. The merging has to be done at the site where the discrepancy is observed, from where it is propagated again.
remsync works
remsync
remsync works
How does remsync keep track of what is in sync, and what isn't?
See section Format of the `.remsync' file, for a the documentation on the `.remsync' file
format. I understand that a mere description of the format does not
replace an explanation, but in the meantime, you might guess from the
format how the program works.
All files are summarized by a checksum, computed by the sum program.
There are a few variants of sum computing checksums in incompatible
ways, under the control of options. remsync attempts to retrieve on
each site a compatible way to do it, and complains if it cannot.
remsync does not compare dates or sizes. Experience shown that the
best version of a file is not necessarily the one with the latest
timestamp. The best version for a site is the current version on this
site, as decided by its maintainer there, and this is this version
that will be propagated.
Each site has an idea of the checksum of a file for all other sites. These checksums are not necessarily identical, for sites do not necessarily propagate to all others, and the propagation network maybe incomplete or asymmetrical in various ways.
Propagation is never done unattended. The user on a site has to call
remsync broadcast to issue synchronization packages for other sites.
If this is never done, the local modifications will never leave the
site. The user also has to call remsync process to apply received
synchronization packages. Applying a package does not automatically
broadcast it further (maybe this could change?).
If a site A propagates some files to sites B and D, but not C, site B is informed that site D also received these files, and site D is informed that site B also received these files, so they will not propagate again the same files to one another. However, both site B and D are susceptible to propagate further the same files to site C.
It may happen that a site refuses to update a file, or modifies a file after having been received, or merges versions, or whatever. So, sites may have a wrong opinion of the file contents on other sites. These differences level down after a few exchanges, and it is very unlikely that a file would not be propagated when it should have.
This scheme works only when the various people handling the various
files have confidence in one each other. If site B modifies a
file after having received it from site A, the file will
eventually be propagated back to site A. If the original file
stayed undisturbed on site A, that is, if remsync proves
that site B correctly knew the checksum of the original file, then
the file will be replaced on site A without any user confirmation.
So, the user on site A has to trust the changes made by the user on site
B.
If the original file on site A had been modified after having been sent in a synchronization package, than it is the responsibility of the user on site A to correctly merge the local modifications with the modifications observed in the file as received from site B. This responsibility is real, since the merged file will later be propagated to the other sites in an authoritative way.
remsync