Add .hg dir exclude to default_cvsignore list.

[rsync/rsync.git] / rsync.yo

diff --git a/rsync.yo b/rsync.yo
index 0ad14f3..65daed5 100644 (file)
--- a/rsync.yo
+++ b/rsync.yo
@@ -781,7 +781,9 @@ quote(itemization(
   it() The file's data will be in an inconsistent state during the transfer
   and will be left that way if the transfer is interrupted or if an update
   fails.
-  it() A file that does not have write permissions cannot be updated.
+  it() A file that rsync cannot write to cannot be updated. While a super user
+  can update any file, a normal user needs to be granted write permission for
+  the open of the file for writing to be successful.
   it() The efficiency of rsync's delta-transfer algorithm may be reduced if
   some data in the destination file is overwritten before it can be copied to
   a position later in the file.  This does not apply if you use bf(--backup),
@@ -794,7 +796,8 @@ accessed by others, so be careful when choosing to use this for a copy.
 
 This option is useful for transferring large files with block-based changes
 or appended data, and also on systems that are disk bound, not network
-bound.
+bound.  It can also help keep a copy-on-write filesystem snapshot from
+diverging the entire contents of a file that only has minor changes.
 
 The option implies bf(--partial) (since an interrupted transfer does not delete
 the file), but conflicts with bf(--partial-dir) and bf(--delay-updates).
@@ -960,7 +963,10 @@ see the bf(--inplace) option for more caveats).
 If incremental recursion is active (see bf(--recursive)), rsync may transfer
 a missing hard-linked file before it finds that another link for that contents
 exists elsewhere in the hierarchy.  This does not affect the accuracy of
-the transfer, just its efficiency.  One way to avoid this is to disable
+the transfer (i.e. which files are hard-linked together), just its efficiency
+(i.e. copying the data for a new, early copy of a hard-linked file that could
+have been found later in the transfer in another member of the hard-linked
+set of files).  One way to avoid this inefficiency is to disable
 incremental recursion using the bf(--no-inc-recursive) option.
 
 dit(bf(-p, --perms)) This option causes the receiving rsync to set the
@@ -1483,7 +1489,7 @@ initial items are marked as perishable -- see the FILTER RULES section):
 
 quote(quote(tt(RCS SCCS CVS CVS.adm RCSLOG cvslog.* tags TAGS .make.state
 .nse_depinfo *~ #* .#* ,* _$* *$ *.old *.bak *.BAK *.orig *.rej .del-*
-*.a *.olb *.o *.obj *.so *.exe *.Z *.elc *.ln core .svn/ .git/ .bzr/)))
+*.a *.olb *.o *.obj *.so *.exe *.Z *.elc *.ln core .svn/ .git/ .hg/ .bzr/)))
 
 then, files listed in a $HOME/.cvsignore are added to the list and any
 files listed in the CVSIGNORE environment variable (all cvsignore names
@@ -1613,6 +1619,12 @@ bf(--files-from) filenames are being sent from one host to another, the
 filenames will be translated from the sending host's charset to the
 receiving host's charset.
 
+NOTE: sorting the list of files in the --files-from input helps rsync to be
+more efficient, as it will avoid re-visiting the path elements that are shared
+between adjacent entries.  If the input is not sorted, some path elements
+(implied directories) may end up being scanned multiple times, and rsync will
+eventually unduplicate them after they get turned into file-list elements.
+
 dit(bf(-0, --from0)) This tells rsync that the rules/filenames it reads from a
 file are terminated by a null ('\0') character, not a NL, CR, or CR+LF.
 This affects bf(--exclude-from), bf(--include-from), bf(--files-from), and any