No subject

does. DM should know just how to =E2=80=9Ccommit=E2=80=9D a newly created r=
evision
into repository (KisMementoManager class) and =E2=80=9Ccheckout=E2=80=9C so=
me
previously created one. And no ensureTileMementoed() needed.

Well, that was an idea. Here are details about implementation.

How am I going to throw away ensureTileMementoed? COWing. We should
base all our system on COWing. Lets imagine...

Once upon a time there was a Memento Manager. He was very pedantic and
knew history of every citizen (tile) in his town. He stored it in a
list that was called m_revisionsList. It consisted of smaller lists of
KisMementos which stored citizen's accomodation (m_col, m_row) and
state (m_tileData). How did he know everybody's history? It's simple!
They said it to him themselves! Every time a tile wanted to write some
data (KisTile::lockForWrite called) it checked whether there were some
other users of the tile-data (TD). If there were some, it got new
piece of tile-data and registered it in a Memento Manager's office
(KisMementoManager ::registerTileData(td, col, row)) saying: =E2=80=9CHey,
doc! I've got a new data!=E2=80=9D. The Memento Manager saved this TD in a
temporary list (m_indexList) called =E2=80=9Cindex=E2=80=9D (do you remembe=
r =E2=80=9Cindex=E2=80=9D
term in Git?) and incremented KisTileData::m_refCount counter. By this
time TD structure had only one COW-user (it was our KisTile object),
so all lockForWrite() calls wouldn't cause any COWing. But TD-object
itself couldn't be freely deleted from memory and corrupt
m_indexList's pointres, because The Manager held it's m_refCount
counter.

Time flied and DM decided to make a commit. He said about it to The
Memento Manager (KisMementoManager::commit()) and the latter one
appended m_indexList into the end of m_revisionsList acquiring all
items of index for COW'ing (incrementing KisTileData::m_usersCount).