Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

[Refs] Fixed refs displaying incorrectly #17802

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jan 24, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 6 additions & 2 deletions 8 components/lock.rst
Original file line number Diff line number Diff line change
Expand Up @@ -310,7 +310,7 @@ will fallback to a write lock by calling the ``acquire()`` method.
The Owner of The Lock
---------------------

Locks that are acquired for the first time are owned [1]_ by the ``Lock`` instance that acquired
Locks that are acquired for the first time are :ref:`owned <lock-owner-technical-details>` by the ``Lock`` instance that acquired
it. If you need to check whether the current ``Lock`` instance is (still) the owner of
a lock, you can use the ``isAcquired()`` method::

Expand Down Expand Up @@ -347,7 +347,11 @@ lose the lock it acquired automatically::
you have to use ``acquire()`` for this. The ``isAcquired()`` method is used to check
if the lock has been acquired by the **current process** only.

.. [1] Technically, the true owners of the lock are the ones that share the same instance of ``Key``,
.. _lock-owner-technical-details:

.. note::

Technically, the true owners of the lock are the ones that share the same instance of ``Key``,
not ``Lock``. But from a user perspective, ``Key`` is internal and you will likely only be working
with the ``Lock`` instance so it's easier to think of the ``Lock`` instance as being the one that
is the owner of the lock.
Expand Down
13 changes: 9 additions & 4 deletions 13 contributing/code/core_team.rst
Original file line number Diff line number Diff line change
Expand Up @@ -146,7 +146,7 @@ Pull Request Merging Policy

A pull request **can be merged** if:

* It is a minor change [1]_;
* It is a :ref:`minor change <core-team_minor-changes>`;

* Enough time was given for peer reviews;

Expand All @@ -162,7 +162,8 @@ Pull Request Merging Process
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

All code must be committed to the repository through pull requests, except for
minor changes [1]_ which can be committed directly to the repository.
:ref:`minor change <core-team_minor-changes>` which can be committed directly
to the repository.

**Mergers** must always use the command-line ``gh`` tool provided by the
**Project Leader** to merge the pull requests.
Expand All @@ -178,8 +179,12 @@ Symfony Core Rules and Protocol Amendments
The rules described in this document may be amended at any time at the
discretion of the **Project Leader**.

.. [1] Minor changes comprise typos, DocBlock fixes, code standards
violations, and minor CSS, JavaScript and HTML modifications.
.. _core-team_minor-changes:

.. note::

Minor changes comprise typos, DocBlock fixes, code standards
violations, and minor CSS, JavaScript and HTML modifications.

.. _`symfony-docs repository`: https://github.com/symfony/symfony-docs
.. _`fabpot`: https://github.com/fabpot/
Expand Down
Morty Proxy This is a proxified and sanitized view of the page, visit original site.