BIND 10 trac2267, updated. 5784101c08e8318a6e88bea598cf2a7ac5a389c3 [2267] comment updates

[BIND 10 source code commits]

The branch, trac2267 has been updated
       via  5784101c08e8318a6e88bea598cf2a7ac5a389c3 (commit)
      from  fee99a5bb5b064ee62866f93b75b22c99905dc05 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 5784101c08e8318a6e88bea598cf2a7ac5a389c3
Author: JINMEI Tatuya <jinmei at isc.org>
Date:   Wed Sep 19 09:38:05 2012 -0700

    [2267] comment updates

-----------------------------------------------------------------------

Summary of changes:
 src/lib/datasrc/memory/memory_client.cc |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

-----------------------------------------------------------------------
diff --git a/src/lib/datasrc/memory/memory_client.cc b/src/lib/datasrc/memory/memory_client.cc
index e513d37..46999df 100644
--- a/src/lib/datasrc/memory/memory_client.cc
+++ b/src/lib/datasrc/memory/memory_client.cc
@@ -480,16 +480,16 @@ public:
 // The current internal implementation expects that both a normal
 // (non RRSIG) RRset and (when signed) its RRSIG are added at once.
 // Also in the current implementation, the input sequence of RRsets
-// are grouped with their owner name (so if the owner name is changed
+// are grouped with their owner name (so once a new owner name is encountered,
 // no subsequent RRset has the previous owner name), but the ordering
 // in the same group is not fixed.  So we hold all RRsets of the same
-// owner name in node_rrsets_ and node_rrsets_, and add the matching
+// owner name in node_rrsets_ and node_rrsigsets_, and add the matching
 // pairs of RRsets to the zone when we see a new owner name.
 //
 // The caller is responsible for adding the RRsets of the last group
 // in the input sequence by explicitly calling flushNodeRRsets() at the
-// end.  It's cleaner and more robust if we let the destructor of this class,
-// but since we cannot guarantee the adding operation is exception free,
+// end.  It's cleaner and more robust if we let the destructor of this class
+// do it, but since we cannot guarantee the adding operation is exception free,
 // we don't choose that option to maintain the common expectation for
 // destructors.
 class InMemoryClient::Loader : boost::noncopyable {