Use next(it), not it.next() and drop the helpers fallback

[bup.git] / DESIGN

diff --git a/DESIGN b/DESIGN
index 3cfaa5f44bdd0f0a9fe8918cfba482e7e8417c03..97dc96d5cb9cfbb6ff95b96ed4a2b22f25576b9b 100644 (file)
--- a/DESIGN
+++ b/DESIGN
@@ -116,7 +116,7 @@ giant tarball each day, then send that tarball to bup, bup will be able to
 efficiently store only the changes to that tarball from one day to the next. 
 For small files, bup's compression won't be as good as xdelta's, but for
 anything over a few megabytes in size, bup's compression will actually
-*work*, which is a bit advantage over xdelta.
+*work*, which is a big advantage over xdelta.
 
 How does hashsplitting work?  It's deceptively simple.  We read through the
 file one byte at a time, calculating a rolling checksum of the last 64
@@ -251,7 +251,7 @@ relatively infrequently.  (You might think you change your source code
 "frequently" and that git handles much more frequent changes than, say, svn
 can handle.  But that's not the same kind of "frequently" we're talking
 about.  Imagine you're backing up all the files on your disk, and one of
-those files is a 100 GB database file with hundreds of daily users.  You
+those files is a 100 GB database file with hundreds of daily users.  Your
 disk changes so frequently you can't even back up all the revisions even if
 you were backing stuff up 24 hours a day.  That's "frequently.")