rsync - Sep 2002 - Server writes...?

I have a quick question about rsync's writing of files.

	I have a team of people that all use the host BigServer, which is
running rsync as a deamon, as a central place to keep all shared files
backed up.  The "master copy" for any given file is considered to be
the
local file that somebody has worked on -- i.e., BigServer is NOT
considered the master copy.  BigServer is the backup copy.  Team members
back up their files to BigServer periodically with the rsync client.

	Sometimes several team members work on the same file.  In this
case, the team member who most recently rsync'd their local copy up to
BigServer has a backup -- anyone else loses their "BigServer backup
copy"
the instant one of the other team members uploads their version.  (The
semantics are exactly like a team sharing a single Samba share for
backup.)

	The files the team write might be big, as in several dozen or
hundreds of megs.

	Now to my question: What happens if three team members all try to
write the same huge file to BigServer at "the same time"?  Meaning,
the
rsync daemon on BigServer gets three connections that start uploading
"/shared_space/bigfile.mov", before any one of the connections has
finished uploading its complete copy?

	Is there any chance that the resulting "/shared_space/bigfile.mov"
on BigServer would have a corrupted copy, because several clients were
uploading at the same time?  Or, does the rsync daemon guarantee that the
last person (the 3rd team member to connect to BigServer) gets to upload
the final, uncorrupted version of "bigfile.mov" to BigServer?

	Any help is greatly appreciated.  I've read all the docs I could
find but did not see this addressed.


Thank You,
Derek Simkowiak
dereks at itsite dot com

P.S.> The above is a hypothetical that illustrates my question.  My
real-world use is using a FAM/IMON-like trigger mechanism to have rsync
automatically distribute updated files to nodes of an LVS cluster.  The
actual trigger mechanism is Linux 2.4's dnotify signal, chosen over
FAM/IMON because no special libraries or kernel options are required.