RFC: acquisition of wlock inside transaction

[FUJIWARA Katsunori]

Ordinarily, wlock is acquired before starting transaction. But
current implementation of localrepository.wlock() allows to newly
acquire wlock even inside transaction.

If wlock is newly acquired inside transaction, wlock will be released
before closing transaction and in-memory changes of dirstate are
written out at that time. Then:

  - changed dirstate shouldn't be visible to external process until
    closing transaction, because it might contain reference to a
    revision not yet visible to external process

    This problem can be resolved by passing
    'self.currenttransaction()' to 'dirstate.write()' at releasing
    wlock.

  - at closing transaction, in-memory changes of dirstate will be
    written into .hg/dirstate, but wlock isn't acquired at that
    time

    BTW, current implementation of restoring dirstate
    from "journal.dirstate" at failure of transaction overwrites
    .hg/dirstate unintentionally, if transaction is running
    without wlock. This procedure should examine current
    acquisition of wlock :-<

  - in-memory changes of dirstate might be discarded
    unintentionally, even though it should keep changes until
    closing transaction

    For example, subsequent re-acquisition of wlock implies
    repo.invalidatedirstate(), and it discards in-memory changes, if
    .hg/dirstate file is changed by another process.

    (even though it is very very rare case)

IMHO, for consistency (and simplicity), releasing wlock should be
delayed until closing transaction, if wlock is newly acquired
inside transaction.

Or should we prohibit acquisition of wlock inside transaction ?

But, as far as I confirmed with scenarios in *.t test scripts,
acquisition of wlock inside transaction itself occurs in cases below
(both via bundle2.processbundle()):

  - tags.hgtagsfnodescache.write() to write into .hg/cache/hgtagsfnodes1
  - repoview.trywritehiddencache() to write into .hg/cache/hidden


BTW, "hgtagsfnodes1" cache is "robust" to unknown revision, but
"hidden" cache isn't. If not "robust", all entries in a cache file
contaminated with unknown (head) revisions are treated as invalid.

We might have to work for transactional cache flushing, too (I'm just
researching about acquisition of wlock and awareness of transaction at
writing cache out :-))

----------------------------------------------------------------------
[FUJIWARA Katsunori]                             foozy at lares.dti.ne.jp