#
#
# patch "NEWS"
#  from [13cc96981011b0e0e5311f0cefaa6729f5c7ee2c]
#    to [4b39abf2be06d85ca8a1f4378b016c7bd12f8e35]
# 
# patch "monotone.texi"
#  from [b032773ad367b0b784444aded5c2cbe7750b269d]
#    to [4895e9b745dc790c7100bbc6be45fa60d9e7427f]
#
============================================================
--- NEWS	13cc96981011b0e0e5311f0cefaa6729f5c7ee2c
+++ NEWS	4b39abf2be06d85ca8a1f4378b016c7bd12f8e35
@@ -25,9 +25,10 @@
           values "reverse" (default), "forward", and "both". This controls
           what kind of deltas are stored for new file versions. Forward
           deltas are very fast for netsync, but slow for most other uses.
-          Set this to "both" (or "forward" if you're short on disk space) on
-          an empty db and pull everything into it, to get a database which
-          will be much faster for server usage (especially initial pulls).
+          Set this to "both" (or perhaps "forward" if you're very short on
+          disk space) on an empty db and pull everything into it, to get a
+          database which will be much faster for server usage (especially
+          initial pulls).
 
         Bugs fixed
 
============================================================
--- monotone.texi	b032773ad367b0b784444aded5c2cbe7750b269d
+++ monotone.texi	4895e9b745dc790c7100bbc6be45fa60d9e7427f
@@ -3551,7 +3551,11 @@ @heading Existing vars
 versions of files. Reverse deltas are faster when inspecting recent files,
 while forward deltas are much faster for sending over the network. This
 should probably be set to @samp{both} for a server database, unless disk
-space is limited.
+space is severely limited. Note that as @emph{receiving} deltas involves
+reconstructing the file version that the delta was made against, a server
+using a database with only forward deltas will be somewhat slower at
+receiving new revisions unless your particular history graph is highly
+linear.
 
 Changing this value does not affect deltas that have already been stored.
 @end table