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

Pierre-Yves David pierre-yves.david at ens-lyon.org
Tue May 30 15:16:09 EDT 2017



On 05/30/2017 06:26 PM, Martin von Zweigbergk wrote:
> On Tue, May 30, 2017 at 5:57 AM, Augie Fackler <raf at durin42.com> wrote:
>> On Mon, May 29, 2017 at 12:41 PM, Pierre-Yves David
>> <pierre-yves.david at 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 at ens-lyon.org <mailto:pierre-yves.david at ens-lyon.org>>
>>>> wrote:
>>>>
>>>>     On 05/28/2017 08:15 AM, Martin von Zweigbergk wrote:
>>>>
>>>>         # HG changeset patch
>>>>         # User Martin von Zweigbergk <martinvonz at google.com
>>>>         <mailto:martinvonz at 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,

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list