##// END OF EJS Templates
snapshot: search for unrelated but reusable full-snapshot...
snapshot: search for unrelated but reusable full-snapshot # New Strategy Step: Reusing Snapshot Outside Of Parents' Chain. If no suitable bases were found in the parent's chains, see if we could reuse a full snapshot not directly related to the current revision. Such search can be expensive, so we only search for snapshots appended to the revlog *after* the bases used by the parents of the current revision (the one we just tested). We assume the parent's bases were created because the previous snapshots were unsuitable, so there are low odds they would be useful now. This search gives a chance to reuse a delta chain unrelated to the current revision. Without this re-use, topological branches would keep reopening new full chains. Creating more and more snapshots as the repository grow. In repositories with many topological branches, the lack of delta reuse can create too many snapshots reducing overall compression to nothing. This results in a very large repository and other usability issues. For now, we still focus on creating level-1 snapshots. However, this principle will play a large part in how we avoid snapshot explosion once we have more snapshot levels. # Effects On The Test Repository In the test repository we created, we can see the beneficial effect of such reuse. We need very few level-0 snapshots and the overall revlog size has decreased. The `hg debugrevlog` call, show a "lvl-2" snapshot. It comes from the existing delta logic using the `prev` revision (revlog's tip) as the base. In this specific case, it turns out the tip was a level-1 snapshot. This is a coincidence that can be ignored. Finding and testing against all these unrelated snapshots can have a performance impact at write time. We currently focus on building good deltas chain we build. Performance concern will be dealt with later in another series.

File last commit:

r39231:1e7a462c default
r39529:3ca144f1 default
Show More
node.py
47 lines | 1.5 KiB | text/x-python | PythonLexer
# node.py - basic nodeid manipulation for mercurial
#
# Copyright 2005, 2006 Matt Mackall <mpm@selenic.com>
#
# This software may be used and distributed according to the terms of the
# GNU General Public License version 2 or any later version.
from __future__ import absolute_import
import binascii
# This ugly style has a noticeable effect in manifest parsing
hex = binascii.hexlify
# Adapt to Python 3 API changes. If this ends up showing up in
# profiles, we can use this version only on Python 3, and forward
# binascii.unhexlify like we used to on Python 2.
def bin(s):
try:
return binascii.unhexlify(s)
except binascii.Error as e:
raise TypeError(e)
nullrev = -1
# In hex, this is '0000000000000000000000000000000000000000'
nullid = b"\0" * 20
nullhex = hex(nullid)
# Phony node value to stand-in for new files in some uses of
# manifests.
# In hex, this is '2121212121212121212121212121212121212121'
newnodeid = '!!!!!!!!!!!!!!!!!!!!'
# In hex, this is '3030303030303030303030303030306164646564'
addednodeid = '000000000000000added'
# In hex, this is '3030303030303030303030306d6f646966696564'
modifiednodeid = '000000000000modified'
wdirfilenodeids = {newnodeid, addednodeid, modifiednodeid}
# pseudo identifiers for working directory
# (they are experimental, so don't add too many dependencies on them)
wdirrev = 0x7fffffff
# In hex, this is 'ffffffffffffffffffffffffffffffffffffffff'
wdirid = b"\xff" * 20
wdirhex = hex(wdirid)
def short(node):
return hex(node[:6])