Patchwork [2,of,8] hidden: rename "revealedrevs" to "anchorrevs"

login
register
mail settings
Submitter via Mercurial-devel
Date May 28, 2017, 6:15 a.m.
Message ID <a0434758fd9a95ea3807.1495952130@martinvonz.svl.corp.google.com>
Download mbox | patch
Permalink /patch/20967/
State Changes Requested
Headers show

Comments

via Mercurial-devel - May 28, 2017, 6:15 a.m.
# HG changeset patch
# User Martin von Zweigbergk <martinvonz@google.com>
# Date 1495944531 25200
#      Sat May 27 21:08:51 2017 -0700
# Node ID a0434758fd9a95ea3807ff4766eaedff6852c628
# Parent  36e6d5d9737962c3a1ec1eef1ef5ebb0a374ffd5
hidden: rename "revealedrevs" to "anchorrevs"

E.g. tags and bookmarks can reveal revisions that would otherwise be
hidden. A revision can also be revealed because one if its descendants
is visible. Let's use the term "anchors" for the former case
(bookmarks etc.).
Pierre-Yves David - May 29, 2017, 3:46 p.m.
On 05/28/2017 08:15 AM, Martin von Zweigbergk wrote:
> # HG changeset patch
> # User Martin von Zweigbergk <martinvonz@google.com>
> # Date 1495944531 25200
> #      Sat May 27 21:08:51 2017 -0700
> # Node ID a0434758fd9a95ea3807ff4766eaedff6852c628
> # Parent  36e6d5d9737962c3a1ec1eef1ef5ebb0a374ffd5
> hidden: rename "revealedrevs" to "anchorrevs"
>
> E.g. tags and bookmarks can reveal revisions that would otherwise be
> hidden. A revision can also be revealed because one if its descendants
> is visible. Let's use the term "anchors" for the former case
> (bookmarks etc.).

Note: With French as my primary language, "anchor" is less clear to me 
than blockers. However I trust native speaker to choose the right terms 
here.

Cheers,
via Mercurial-devel - May 29, 2017, 4:21 p.m.
On May 29, 2017 8:46 AM, "Pierre-Yves David" <pierre-yves.david@ens-lyon.org>
wrote:

On 05/28/2017 08:15 AM, Martin von Zweigbergk wrote:

> # HG changeset patch
> # User Martin von Zweigbergk <martinvonz@google.com>
> # Date 1495944531 25200
> #      Sat May 27 21:08:51 2017 -0700
> # Node ID a0434758fd9a95ea3807ff4766eaedff6852c628
> # Parent  36e6d5d9737962c3a1ec1eef1ef5ebb0a374ffd5
> hidden: rename "revealedrevs" to "anchorrevs"
>
> E.g. tags and bookmarks can reveal revisions that would otherwise be
> hidden. A revision can also be revealed because one if its descendants
> is visible. Let's use the term "anchors" for the former case
> (bookmarks etc.).
>

Note: With French as my primary language, "anchor" is less clear to me than
blockers. However I trust native speaker to choose the right terms here.


"pinned revs" might also have worked. Anchor makes it clearer that they're
also holding up other revs (their ancestors), but that is also true for
other visible revs, so in a way "pinned" may be more accurate. What do you
(all) think?


Cheers,
Pierre-Yves David - May 29, 2017, 4:41 p.m.
On 05/29/2017 06:21 PM, Martin von Zweigbergk wrote:
>
>
> On May 29, 2017 8:46 AM, "Pierre-Yves David"
> <pierre-yves.david@ens-lyon.org <mailto:pierre-yves.david@ens-lyon.org>>
> wrote:
>
>     On 05/28/2017 08:15 AM, Martin von Zweigbergk wrote:
>
>         # HG changeset patch
>         # User Martin von Zweigbergk <martinvonz@google.com
>         <mailto:martinvonz@google.com>>
>         # Date 1495944531 25200
>         #      Sat May 27 21:08:51 2017 -0700
>         # Node ID a0434758fd9a95ea3807ff4766eaedff6852c628
>         # Parent  36e6d5d9737962c3a1ec1eef1ef5ebb0a374ffd5
>         hidden: rename "revealedrevs" to "anchorrevs"
>
>         E.g. tags and bookmarks can reveal revisions that would otherwise be
>         hidden. A revision can also be revealed because one if its
>         descendants
>         is visible. Let's use the term "anchors" for the former case
>         (bookmarks etc.).
>
>
>     Note: With French as my primary language, "anchor" is less clear to
>     me than blockers. However I trust native speaker to choose the right
>     terms here.
>
>
> "pinned revs" might also have worked. Anchor makes it clearer that
> they're also holding up other revs (their ancestors), but that is also
> true for other visible revs, so in a way "pinned" may be more accurate.
> What do you (all) think?

I like pinned better (thank!)

Cheers,
Augie Fackler - May 30, 2017, 12:57 p.m.
On Mon, May 29, 2017 at 12:41 PM, Pierre-Yves David
<pierre-yves.david@ens-lyon.org> wrote:
>
>
> On 05/29/2017 06:21 PM, Martin von Zweigbergk wrote:
>>
>>
>>
>> On May 29, 2017 8:46 AM, "Pierre-Yves David"
>> <pierre-yves.david@ens-lyon.org <mailto:pierre-yves.david@ens-lyon.org>>
>> wrote:
>>
>>     On 05/28/2017 08:15 AM, Martin von Zweigbergk wrote:
>>
>>         # HG changeset patch
>>         # User Martin von Zweigbergk <martinvonz@google.com
>>         <mailto:martinvonz@google.com>>
>>         # Date 1495944531 25200
>>         #      Sat May 27 21:08:51 2017 -0700
>>         # Node ID a0434758fd9a95ea3807ff4766eaedff6852c628
>>         # Parent  36e6d5d9737962c3a1ec1eef1ef5ebb0a374ffd5
>>         hidden: rename "revealedrevs" to "anchorrevs"
>>
>>         E.g. tags and bookmarks can reveal revisions that would otherwise
>> be
>>         hidden. A revision can also be revealed because one if its
>>         descendants
>>         is visible. Let's use the term "anchors" for the former case
>>         (bookmarks etc.).
>>
>>
>>     Note: With French as my primary language, "anchor" is less clear to
>>     me than blockers. However I trust native speaker to choose the right
>>     terms here.
>>
>>
>> "pinned revs" might also have worked. Anchor makes it clearer that
>> they're also holding up other revs (their ancestors), but that is also
>> true for other visible revs, so in a way "pinned" may be more accurate.
>> What do you (all) think?
>
>
> I like pinned better (thank!)

I might go with "pinning" rather than "pinned", that is:

pinning revs: the ones that force otherwise-hidden revisions to be visible
pinned revs: revisions which would otherwise be hidden but are visible

Not sure if that is a useful thought.

>
> Cheers,
>
> --
> Pierre-Yves David
via Mercurial-devel - May 30, 2017, 4:26 p.m.
On Tue, May 30, 2017 at 5:57 AM, Augie Fackler <raf@durin42.com> wrote:
> On Mon, May 29, 2017 at 12:41 PM, Pierre-Yves David
> <pierre-yves.david@ens-lyon.org> wrote:
>>
>>
>> On 05/29/2017 06:21 PM, Martin von Zweigbergk wrote:
>>>
>>>
>>>
>>> On May 29, 2017 8:46 AM, "Pierre-Yves David"
>>> <pierre-yves.david@ens-lyon.org <mailto:pierre-yves.david@ens-lyon.org>>
>>> wrote:
>>>
>>>     On 05/28/2017 08:15 AM, Martin von Zweigbergk wrote:
>>>
>>>         # HG changeset patch
>>>         # User Martin von Zweigbergk <martinvonz@google.com
>>>         <mailto:martinvonz@google.com>>
>>>         # Date 1495944531 25200
>>>         #      Sat May 27 21:08:51 2017 -0700
>>>         # Node ID a0434758fd9a95ea3807ff4766eaedff6852c628
>>>         # Parent  36e6d5d9737962c3a1ec1eef1ef5ebb0a374ffd5
>>>         hidden: rename "revealedrevs" to "anchorrevs"
>>>
>>>         E.g. tags and bookmarks can reveal revisions that would otherwise
>>> be
>>>         hidden. A revision can also be revealed because one if its
>>>         descendants
>>>         is visible. Let's use the term "anchors" for the former case
>>>         (bookmarks etc.).
>>>
>>>
>>>     Note: With French as my primary language, "anchor" is less clear to
>>>     me than blockers. However I trust native speaker to choose the right
>>>     terms here.
>>>
>>>
>>> "pinned revs" might also have worked. Anchor makes it clearer that
>>> they're also holding up other revs (their ancestors), but that is also
>>> true for other visible revs, so in a way "pinned" may be more accurate.
>>> What do you (all) think?
>>
>>
>> I like pinned better (thank!)
>
> I might go with "pinning" rather than "pinned", that is:
>
> pinning revs: the ones that force otherwise-hidden revisions to be visible
> pinned revs: revisions which would otherwise be hidden but are visible

I was actually arguing that the "forces other hidden revisions to
become visible" aspect should not be part of it. Consider this graph:

o E
|
x D
|
| x C bookmark1
| |
| x B
|/
o A

I would call C a pinned rev because it has the bookmark pointing to
it. But also note that B and D are both revealed, the former because
of C and the latter because of E. The point is that B is not
(directly) revealed because of the bookmark, but because C is visible.
It's subtle, but do you agree about the point? So these revisions are
just overriding what hideablerevs() says should be hidden.

That also makes me realize that we can simplify even further. The
initial set of hidden nodes, before revealing ancestors, is simply
"hideablerevs() - pinnedrevs()". More patches coming up :-)

>
> Not sure if that is a useful thought.
>
>>
>> Cheers,
>>
>> --
>> Pierre-Yves David
Augie Fackler - May 30, 2017, 4:48 p.m.
On Tue, May 30, 2017 at 12:26 PM, Martin von Zweigbergk
<martinvonz@google.com> wrote:
> o E
> |
> x D
> |
> | x C bookmark1
> | |
> | x B
> |/
> o A
>
> I would call C a pinned rev because it has the bookmark pointing to
> it. But also note that B and D are both revealed, the former because
> of C and the latter because of E. The point is that B is not
> (directly) revealed because of the bookmark, but because C is visible.
> It's subtle, but do you agree about the point?

Yeah, that makes sense.

> So these revisions are
> just overriding what hideablerevs() says should be hidden.
>
> That also makes me realize that we can simplify even further. The
> initial set of hidden nodes, before revealing ancestors, is simply
> "hideablerevs() - pinnedrevs()". More patches coming up :-)

Nice.

>
>>
>> Not sure if that is a useful thought.
>>
>>>
>>> Cheers,
>>>
>>> --
>>> Pierre-Yves David
Pierre-Yves David - May 30, 2017, 7:16 p.m.
On 05/30/2017 06:26 PM, Martin von Zweigbergk wrote:
> On Tue, May 30, 2017 at 5:57 AM, Augie Fackler <raf@durin42.com> wrote:
>> On Mon, May 29, 2017 at 12:41 PM, Pierre-Yves David
>> <pierre-yves.david@ens-lyon.org> wrote:
>>>
>>>
>>> On 05/29/2017 06:21 PM, Martin von Zweigbergk wrote:
>>>>
>>>>
>>>>
>>>> On May 29, 2017 8:46 AM, "Pierre-Yves David"
>>>> <pierre-yves.david@ens-lyon.org <mailto:pierre-yves.david@ens-lyon.org>>
>>>> wrote:
>>>>
>>>>     On 05/28/2017 08:15 AM, Martin von Zweigbergk wrote:
>>>>
>>>>         # HG changeset patch
>>>>         # User Martin von Zweigbergk <martinvonz@google.com
>>>>         <mailto:martinvonz@google.com>>
>>>>         # Date 1495944531 25200
>>>>         #      Sat May 27 21:08:51 2017 -0700
>>>>         # Node ID a0434758fd9a95ea3807ff4766eaedff6852c628
>>>>         # Parent  36e6d5d9737962c3a1ec1eef1ef5ebb0a374ffd5
>>>>         hidden: rename "revealedrevs" to "anchorrevs"
>>>>
>>>>         E.g. tags and bookmarks can reveal revisions that would otherwise
>>>> be
>>>>         hidden. A revision can also be revealed because one if its
>>>>         descendants
>>>>         is visible. Let's use the term "anchors" for the former case
>>>>         (bookmarks etc.).
>>>>
>>>>
>>>>     Note: With French as my primary language, "anchor" is less clear to
>>>>     me than blockers. However I trust native speaker to choose the right
>>>>     terms here.
>>>>
>>>>
>>>> "pinned revs" might also have worked. Anchor makes it clearer that
>>>> they're also holding up other revs (their ancestors), but that is also
>>>> true for other visible revs, so in a way "pinned" may be more accurate.
>>>> What do you (all) think?
>>>
>>>
>>> I like pinned better (thank!)
>>
>> I might go with "pinning" rather than "pinned", that is:
>>
>> pinning revs: the ones that force otherwise-hidden revisions to be visible
>> pinned revs: revisions which would otherwise be hidden but are visible
>
> I was actually arguing that the "forces other hidden revisions to
> become visible" aspect should not be part of it. Consider this graph:
>
> o E
> |
> x D
> |
> | x C bookmark1
> | |
> | x B
> |/
> o A
>
> I would call C a pinned rev because it has the bookmark pointing to
> it. But also note that B and D are both revealed, the former because
> of C and the latter because of E. The point is that B is not
> (directly) revealed because of the bookmark, but because C is visible.
> It's subtle, but do you agree about the point? So these revisions are
> just overriding what hideablerevs() says should be hidden.
>
> That also makes me realize that we can simplify even further. The
> initial set of hidden nodes, before revealing ancestors, is simply
> "hideablerevs() - pinnedrevs()". More patches coming up :-)

That seems like a good idea.

Cheers,

Patch

diff --git a/hgext/rebase.py b/hgext/rebase.py
--- a/hgext/rebase.py
+++ b/hgext/rebase.py
@@ -1537,4 +1537,4 @@ 
     cmdutil.afterresolvedstates.append(
         ['rebasestate', _('hg rebase --continue')])
     # ensure rebased rev are not hidden
-    extensions.wrapfunction(repoview, 'revealedrevs', _rebasedvisible)
+    extensions.wrapfunction(repoview, 'anchorrevs', _rebasedvisible)
diff --git a/mercurial/repoview.py b/mercurial/repoview.py
--- a/mercurial/repoview.py
+++ b/mercurial/repoview.py
@@ -28,21 +28,21 @@ 
     lead to crashes."""
     return obsolete.getrevs(repo, 'obsolete')
 
-def revealedrevs(repo):
+def anchorrevs(repo):
     """revisions blocking hidden changesets from being filtered
     """
 
     cl = repo.changelog
-    blockers = set()
-    blockers.update([par.rev() for par in repo[None].parents()])
-    blockers.update([cl.rev(bm) for bm in repo._bookmarks.values()])
+    anchors = set()
+    anchors.update([par.rev() for par in repo[None].parents()])
+    anchors.update([cl.rev(bm) for bm in repo._bookmarks.values()])
 
     tags = {}
     tagsmod.readlocaltags(repo.ui, repo, tags, {})
     if tags:
         rev, nodemap = cl.rev, cl.nodemap
-        blockers.update(rev(t[0]) for t in tags.values() if t[0] in nodemap)
-    return blockers
+        anchors.update(rev(t[0]) for t in tags.values() if t[0] in nodemap)
+    return anchors
 
 def _consistencyblocker(pfunc, hideable, domain):
     """return non-hideable changeset blocking hideable one
@@ -112,7 +112,7 @@ 
 
         # check if we have wd parents, bookmarks or tags pointing to hidden
         # changesets and remove those.
-        blockers |= (hidden & revealedrevs(repo))
+        blockers |= (hidden & anchorrevs(repo))
         if blockers:
             hidden = hidden - _domainancestors(pfunc, blockers, mutable)
     return frozenset(hidden)