tests/test-known.t

hg: make cachedlocalrepo cache appropriate repoview object

Before this patch, 'cachedlocalrepo' always caches "visible" repoview
object, because 'cachedlocalrepo' uses "visible" repoview returned by
'hg.repository()' without any additional processing.

If the client of 'cachedlocalrepo' wants "served" repoview, some
objects to be cached are discarded unintentionally.

    1. 'cachedlocalrepo' newly caches "visible" repoview object
       (call it VIEW1)

    2. 'cachedlocalrepo' returns VIEW1 to the client of it at 'fetch()'

    3. the client gets "served" repoview object by 'filtered("served")'
       on VIEW1 (call this "served" repoview VIEW2)

    4. accessing to 'repo.changelog' implies:
       - instantiation of changelog via 'localrepository.changelog'
       - instantiation of "filtered changelog" via 'repoview.changelog'

    5. "filtered changelog" above is cached in VIEW2

    6. VIEW2 is discarded after processing, because there is no
       reference to it

    7. 'cachedlocalrepo' returns VIEW1 cached at (1) above to the
       client at next 'fetch()'

    8. 'filtered("served")' on VIEW1 at the client side creates new
       "served" repoview again, because VIEW1 is "visible"
       (call this new "served" repoview VIEW3)

    9. accessing to 'repo.changelog' implies instantiation of filtered
       changelog again, because "filtered changelog" is cached in
       VIEW2 at (5), but not in VIEW3 currently used

    10. (go to (7) above)

As described above, "served" repoview object and "filtered changelog"
cached in it are discarded always, even if the repository itself
hasn't been changed since last access.

For example, in the case of 'hgweb_mod.hgweb', "newly caching" occurs,
when:

  - all cached objects are already assigned to another threads
    (in this case, repoview is created in 'cachedlocalrepo.copy()')

  - or, stat of '00changelog.i' is changed from last access
    (in this case, repoview is created in 'cachedlocalrepo.fetch()')

    once changes are pushed via HTTP, this always occurs.

The root cause of this inefficiency is that 'cachedlocalrepo' always
caches "visible" repoview object, even if the client of it wants
another view.

To make 'cachedlocalrepo' cache appropriate repoview object, this
patch adds additional filtering on the repo object returned by
'hg.repository()'. It is assumed that initial repoview object should
be already filtered by expected view.

After this patch:

  - 'filtered("served")' on VIEW1 at (3)/(7) above returns VIEW1
    itself, because VIEW1 is now "served", and

  - VIEW2 and VIEW3 equal VIEW1

  - therefore, "filtered changelog" is cached in VIEW1, and reused
    intentionally

#require killdaemons

= Test the known() protocol function =

Create a test repository:

  $ hg init repo
  $ cd repo
  $ touch a ; hg add a ; hg ci -ma
  $ touch b ; hg add b ; hg ci -mb
  $ touch c ; hg add c ; hg ci -mc
  $ hg log --template '{node}\n'
  991a3460af53952d10ec8a295d3d2cc2e5fa9690
  0e067c57feba1a5694ca4844f05588bb1bf82342
  3903775176ed42b1458a6281db4a0ccf4d9f287a
  $ cd ..

Test locally:

  $ hg debugknown repo 991a3460af53952d10ec8a295d3d2cc2e5fa9690 0e067c57feba1a5694ca4844f05588bb1bf82342 3903775176ed42b1458a6281db4a0ccf4d9f287a
  111
  $ hg debugknown repo 000a3460af53952d10ec8a295d3d2cc2e5fa9690 0e067c57feba1a5694ca4844f05588bb1bf82342 0003775176ed42b1458a6281db4a0ccf4d9f287a
  010
  $ hg debugknown repo
  

Test via HTTP:

  $ hg serve -R repo -p $HGPORT -d --pid-file=hg.pid -E error.log -A access.log
  $ cat hg.pid >> $DAEMON_PIDS
  $ hg debugknown http://localhost:$HGPORT/ 991a3460af53952d10ec8a295d3d2cc2e5fa9690 0e067c57feba1a5694ca4844f05588bb1bf82342 3903775176ed42b1458a6281db4a0ccf4d9f287a
  111
  $ hg debugknown http://localhost:$HGPORT/ 000a3460af53952d10ec8a295d3d2cc2e5fa9690 0e067c57feba1a5694ca4844f05588bb1bf82342 0003775176ed42b1458a6281db4a0ccf4d9f287a
  010
  $ hg debugknown http://localhost:$HGPORT/
  
  $ cat error.log
  $ killdaemons.py