Mention some chanages in the patches dir.

[rsync/rsync.git] / rsync.yo

diff --git a/rsync.yo b/rsync.yo
index 60149d6..5094c8a 100644 (file)
--- a/rsync.yo
+++ b/rsync.yo
@@ -3,20 +3,20 @@ manpage(rsync)(1)(28 Jul 2005)()()
 manpagename(rsync)(faster, flexible replacement for rcp)
 manpagesynopsis()
 
+rsync [OPTION]... SRC [SRC]... DEST
+
 rsync [OPTION]... SRC [SRC]... [USER@]HOST:DEST
 
-rsync [OPTION]... [USER@]HOST:SRC [DEST]
+rsync [OPTION]... SRC [SRC]... [USER@]HOST::DEST
 
-rsync [OPTION]... SRC [SRC]... DEST
+rsync [OPTION]... SRC [SRC]... rsync://[USER@]HOST[:PORT]/DEST
 
-rsync [OPTION]... [USER@]HOST::SRC [DEST]
+rsync [OPTION]... [USER@]HOST:SRC [DEST]
 
-rsync [OPTION]... SRC [SRC]... [USER@]HOST::DEST
+rsync [OPTION]... [USER@]HOST::SRC [DEST]
 
 rsync [OPTION]... rsync://[USER@]HOST[:PORT]/SRC [DEST]
 
-rsync [OPTION]... SRC [SRC]... rsync://[USER@]HOST[:PORT]/DEST
-
 manpagedescription()
 
 rsync is a program that behaves in much the same way that rcp does,
@@ -1260,10 +1260,13 @@ Conflicts with bf(--inplace).
 This option uses more memory on the receiving side (one bit per file
 transferred) and also requires enough free disk space on the receiving
 side to hold an additional copy of all the updated files.  Note also that
-you should not use an absolute path to bf(--partial-dir) unless there is no
+you should not use an absolute path to bf(--partial-dir) unless (1)
+there is no
 chance of any of the files in the transfer having the same name (since all
 the updated files will be put into a single directory if the path is
-absolute).
+absolute)
+and (2) there are no mount points in the hierarchy (since the
+delayed updates will fail if they can't be renamed into place).
 
 See also the "atomic-rsync" perl script in the "support" subdir for an
 update algorithm that is even more atomic (it uses bf(--link-dest) and a