# HG changeset patch
# User Pierre-Yves David <pierre-yves.david@octobus.net>
# Date 1493845621 -7200
# Node ID 3bb8382fc4cbaf9a913e88a8047b2435a8cdab51
# Parent  7ccacaa387824a965151e99a4a5d8bf6916959e3
obscache: update some documentation

Update some data and do some proof reading.

diff -r 7ccacaa38782 -r 3bb8382fc4cb hgext3rd/evolve/obscache.py
--- a/hgext3rd/evolve/obscache.py	Wed May 03 21:47:06 2017 +0200
+++ b/hgext3rd/evolve/obscache.py	Wed May 03 23:07:01 2017 +0200
@@ -298,13 +298,14 @@
         """update the cache with new revisions
 
         Newly added changeset might be affected by obsolescence markers
-        we already have locally. So we needs to have soem global
-        knowledge about the markers to handle that question. Right this
-        requires parsing all markers in the obsstore. However, we could
-        imagine using various optimisation (eg: bloom filter, other on
-        disk cache) to remove this full parsing.
+        we already have locally. So we needs to have some global
+        knowledge about the markers to handle that question.
 
-        For now we stick to the simpler approach or paying the
+        Right now this requires parsing all markers in the obsstore. We could
+        imagine using various optimisation (eg: another cache, network
+        exchange, etc).
+
+        For now we stick to the simpler approach of paying the
         performance cost on new changesets.
         """
         node = repo.changelog.node
@@ -363,7 +364,7 @@
     if notpublic:
         obscache = repo.obsstore.obscache
         # Since we warm the cache at the end of every transaction, the cache
-        # should be up to date. However a non-enabled client might have touced
+        # should be up to date. However a non-enabled client might have touched
         # the repository.
         #
         # Updating the cache without a lock is sloppy, so we fallback to the
@@ -372,7 +373,7 @@
         #
         # With the current implementation updating the cache will requires to
         # load the obsstore anyway. Once loaded, hitting the obsstore directly
-        # will be about as fast..
+        # will be about as fast...
         if not obscache.uptodate(repo):
             if repo.currenttransaction() is None:
                 repo.ui.log('evoext-obscache',
@@ -381,8 +382,9 @@
                 repo.ui.debug('obscache is out of date')
                 return orig(repo)
             else:
-                # If a transaction is open, it is worthwhile to update and use the
-                # cache as it will be written on disk when the transaction close.
+                # If a transaction is open, it is worthwhile to update and use
+                # the cache, the lock prevent race and it will be written on
+                # disk when the transaction close.
                 obscache.update(repo)
         isobs = obscache.get
     for r in notpublic:
@@ -415,11 +417,10 @@
                 if repo is None:
                     return
                 repo = repo.unfiltered()
-                # As pointed in 'obscache.update', we could have the
-                # changelog and the obsstore in charge of updating the
-                # cache when new items goes it. The tranaction logic would
-                # then only be involved for the 'pending' and final saving
-                # logic.
+                # As pointed in 'obscache.update', we could have the changelog
+                # and the obsstore in charge of updating the cache when new
+                # items goes it. The tranaction logic would then only be
+                # involved for the 'pending' and final writing on disk.
                 self.obsstore.obscache.update(repo)
                 self.obsstore.obscache.save(repo)