delete-delay vs. delete-after in 3.0.2 (and possible bug)

[Michal Soltys]

Wayne Davison wrote:
> 
> Diffs are always welcomed.  Please feel free.
> 
> ..wayne..
> 

Allright, tiny update to the rsync.yo file.

I haven't included information about backup/suffix case you mentioned, 
as I'm not sure about the details yet.

-------------- next part --------------
--- rsync.yo.org	2008-05-17 18:45:28.000000000 +0200
+++ rsync.yo	2008-06-18 22:38:48.000000000 +0200
@@ -1170,6 +1170,13 @@
 using bf(--delete-after) (which it cannot do if bf(--recursive) is doing an
 incremental scan).
 
+bf(--delete-delay) is particulary useful with bf(--delay-updates) option, as
+it avoids an extra dir-scan delete pass in such case.
+
+Note, that bf(--delete-delay) is not equivalent to bf(--delete-after), when
+per-directory rules on the receiving and sending side are different - in such
+case, deletions are computed using old rules.
+
 dit(bf(--delete-after)) Request that the file-deletions on the receiving
 side be done after the transfer has completed.  This is useful if you
 are sending new per-directory merge files as a part of the transfer and