Fundamental rsync design question.

Bennett Todd bet at
Mon Jul 29 11:40:02 EST 2002

2002-07-29-12:11:54 Biju Perumal:
> [ why rsync's design rather than accumulating diffs ]

The approach you describe is quite often used. Look in the
neighborhood of source code control systems used in distributed
ways, and you'll see it all the time. I've also used it in the past
for software distribution and content management.

Rsync has a couple of advantages, that make it a valuable tool as it
stands, and that allow it to sometimes (but not always) encroach on
the turf of such version management systems.

First off, if you want to send pre-generated diffs, you really have
to know what version the receiver has. In general keeping track of
this can be difficult, and it makes it harder to be robust in the
face of updates that fail in the middle of a multi-file update
process; you end up needing to try and implement your patch process
in a transactional fashion, so you can back out all applied patches
if you bomb in the middle.

And second, they impose on the sender the requirement to keep
previous versions for differencing against. Sometimes this is an
awkward requirement --- think using rsync for online backups.

Rsync is an efficient distributed file synchronization tool, that
uses an efficient and clever distributed differencing algorithm.
It's not the best tool for all jobs, but there are many jobs that it
does very well.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url :

More information about the rsync mailing list