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

Yuya Nishihara yuya at tcha.org
Thu Oct 4 08:57:38 EDT 2018


On Thu, 4 Oct 2018 08:09:08 +0200, Boris FELD wrote:
> On 30/09/2018 15:13, Yuya Nishihara wrote:
> > On Thu, 27 Sep 2018 19:08:45 +0200, Boris Feld wrote:
> >> # HG changeset patch
> >> # User Boris Feld <boris.feld at octobus.net>
> >> # Date 1537998614 -7200
> >> #      Wed Sep 26 23:50:14 2018 +0200
> >> # Node ID 1abacb9c2d03520a12af25ae0d9ae5978f6aa3db
> >> # Parent  bd762ec24f1858bc577b05de0388688a7756f6ba
> >> # EXP-Topic trackfold
> >> # Available At https://bitbucket.org/octobus/mercurial-devel/
> >> #              hg pull https://bitbucket.org/octobus/mercurial-devel/ -r 1abacb9c2d03
> >> obsolete: explicitly track folds inside the markers
> > Queued up to the previous patch, dropping the first two which appear to be
> > already in. Thanks.
> >
> > I don't have a strong concern about this patch, but this touches the storage
> > so I think this needs more eyes.
> >
> >> +def makefoldid(relation):
> >> +    folddata = ''.join(p.node() for p in relation[0] + relation[1])
> >> +    # Since fold only has to compete against fold for the same successors, it
> > Does it mean there's no reason to include relation[1] in the hash?
> It is probably still useful to have an id as unique as possible. The
> goal here is more about producing a unique identifier than a
> reproducible one. In fact, we should probably also include local
> revisions numbers and users to help distinguish between two similar but
> independent fold.

Can you add that to the inline comment? I was confused about that because the
code didn't follow what the comment says.


More information about the Mercurial-devel mailing list