[PATCH 2 of 2] obsolete: explicitly track folds inside the markers

Boris Feld boris.feld at octobus.net
Thu Oct 4 02:21:41 EDT 2018


# HG changeset patch
# User Boris Feld <boris.feld at octobus.net>
# Date 1537998614 -7200
#      Wed Sep 26 23:50:14 2018 +0200
# Node ID 2121abaa4b8dbd435785b657ec2574eb308ff2b8
# Parent  8bb49aafe1d75c02f40248126969611ca78b76e8
# EXP-Topic trackfold
# Available At https://bitbucket.org/octobus/mercurial-devel/
#              hg pull https://bitbucket.org/octobus/mercurial-devel/ -r 2121abaa4b8d
obsolete: explicitly track folds inside the markers

We know records information to be able to recognize "fold" event from
obsolescence markers. To do so, we track the following piece of information:

a) a fold ID. Unique to that fold (per successors),
b) the number of predecessors,
c) the index of the predecessor in that fold.

We will now be able to create algorithm able to find "predecessorssets".

We now store this data in the generic "metadata" field of the markers.
Updating the format to have a more compact storage for this would be useful.

This way of tracking a fold through multiple markers could be applied to split
too. This would have two advantages:

1) We get a simpler format, since successors numbers are limited to [0-1].
2) We can better deal with situations where only some of the split successors
   are pushed to a remote repository.

We should look into the relevance of such change before updating the on disk
format.

note: unlike splits, folds do not have to deal with cases where only some of
the markers have been synchronized. As they all share the same successor
changesets, they are all relevant to the same nodes.

diff --git a/mercurial/obsolete.py b/mercurial/obsolete.py
--- a/mercurial/obsolete.py
+++ b/mercurial/obsolete.py
@@ -70,6 +70,7 @@ comment associated with each format for 
 from __future__ import absolute_import
 
 import errno
+import hashlib
 import struct
 
 from .i18n import _
@@ -954,6 +955,15 @@ def _computecontentdivergentset(repo):
             toprocess.update(obsstore.predecessors.get(prec, ()))
     return divergent
 
+def makefoldid(relation, user):
+
+    folddigest = hashlib.sha1(user)
+    for p in relation[0] + relation[1]:
+        folddigest.update('%d' % p.rev())
+        folddigest.update(p.node())
+    # Since fold only has to compete against fold for the same successors, it
+    # seems fine to use a small ID. Smaller ID save space.
+    return node.hex(folddigest.digest())[:8]
 
 def createmarkers(repo, relations, flag=0, date=None, metadata=None,
                   operation=None):
@@ -1000,11 +1010,19 @@ def createmarkers(repo, relations, flag=
             if 1 < len(predecessors) and len(rel[1]) != 1:
                 msg = 'Fold markers can only have 1 successors, not %d'
                 raise error.ProgrammingError(msg % len(rel[1]))
-            for prec in predecessors:
+            foldid = None
+            foldsize = len(predecessors)
+            if 1 < foldsize:
+                foldid = makefoldid(rel, metadata['user'])
+            for foldidx, prec in enumerate(predecessors, 1):
                 sucs = rel[1]
                 localmetadata = metadata.copy()
                 if 2 < len(rel):
                     localmetadata.update(rel[2])
+                if foldid is not None:
+                    localmetadata['fold-id'] = foldid
+                    localmetadata['fold-idx'] = '%d' % foldidx
+                    localmetadata['fold-size'] = '%d' % foldsize
 
                 if not prec.mutable():
                     raise error.Abort(_("cannot obsolete public changeset: %s")
diff --git a/tests/test-rebase-obsolete.t b/tests/test-rebase-obsolete.t
--- a/tests/test-rebase-obsolete.t
+++ b/tests/test-rebase-obsolete.t
@@ -356,9 +356,9 @@ collapse rebase
   $ hg id --debug -r tip
   4dc2197e807bae9817f09905b50ab288be2dbbcf tip
   $ hg debugobsolete
-  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (Thu Jan 01 00:00:00 1970 +0000) {'ef1': '13', 'operation': 'rebase', 'user': 'test'}
-  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (Thu Jan 01 00:00:00 1970 +0000) {'ef1': '13', 'operation': 'rebase', 'user': 'test'}
-  32af7686d403cf45b5d95f2d70cebea587ac806a 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (Thu Jan 01 00:00:00 1970 +0000) {'ef1': '13', 'operation': 'rebase', 'user': 'test'}
+  42ccdea3bb16d28e1848c95fe2e44c000f3f21b1 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (Thu Jan 01 00:00:00 1970 +0000) {'ef1': '13', 'fold-id': '6fb65cdc', 'fold-idx': '1', 'fold-size': '3', 'operation': 'rebase', 'user': 'test'}
+  5fddd98957c8a54a4d436dfe1da9d87f21a1b97b 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (Thu Jan 01 00:00:00 1970 +0000) {'ef1': '13', 'fold-id': '6fb65cdc', 'fold-idx': '2', 'fold-size': '3', 'operation': 'rebase', 'user': 'test'}
+  32af7686d403cf45b5d95f2d70cebea587ac806a 4dc2197e807bae9817f09905b50ab288be2dbbcf 0 (Thu Jan 01 00:00:00 1970 +0000) {'ef1': '13', 'fold-id': '6fb65cdc', 'fold-idx': '3', 'fold-size': '3', 'operation': 'rebase', 'user': 'test'}
 
   $ cd ..
 


More information about the Mercurial-devel mailing list