phase: rename the requirement for internal-phase (BC)
The previous requirements covers both `internal` and `archived` phase. However, the `archived` phase is not ready for usage (while the internal one is mostly ready for years). So we split the archived on in a dedicated requirements (see previous changeset for details) and rename the one for internal-phase. This will avoid older client trying to use the archived phase on `internal` only repositories. Since the requirements stayed experimental since its introduction. It seems fine to drop the previous version.
- mercurial/configitems.py 4 additions, 1 deletionmercurial/configitems.py
- mercurial/localrepo.py 1 addition, 1 deletionmercurial/localrepo.py
- mercurial/requirements.py 1 addition, 1 deletionmercurial/requirements.py
- tests/test-phases.t 3 additions, 3 deletionstests/test-phases.t
- tests/test-shelve.t 1 addition, 1 deletiontests/test-shelve.t
- tests/test-shelve2.t 1 addition, 1 deletiontests/test-shelve2.t
-
This change is causing us a great deal of consternation. As we've been migrating to
internal-phase
for the past ~2 mo, we're now reliant onformat.internal-phase
and alsointernal-phase
as the name of the requirement. Moreover, these new names, particularlyinternal-phase-2
, is debt-ridden and ugly. Can we consider simply reverting this change? -
mentioned in commit d9f88448f8c8
-
mentioned in merge request !230 (closed)
-
These changes are important to be able to get
internal phase
out of experimental in the short term. I'm afraid that some of the fundamentals can't really go away. Mostly, if the requirements name wouldn't change, newer clients could create (on disk) repositories on which older clients could end up using thearchived
phase "by mistake" by accessing the very same files. The name change prevents that by gating to new clients that will understand the requirement as "use theinternal phase
only".The new name can be different if people have strong feelings about it, maybe
internal-phase-only
?phase-internal
?).That being said, the goal is obviously not to cause you trouble and we should see what can be done here. For example, some config aliasing and some extra patches to automatically migrate the old requirement to the new one might be enough to ease the transition on your side. What do you think?
-
Mostly, if the requirements name wouldn't change, newer clients could create (on disk) repositories on which older clients could end up using the
archived
phase "by mistake" by accessing the very same files.I'd gotten the impression that the re-use of
internal-phase
forarchive
was an oversight and sparingly used and additionally protected by thecleanup-as-archived
config. It seemed unlikely to me that someone would havecleanup-as-archive
enabled, butinternal-phase
not (the one condition where older clients would end up using thearchived
phase).On the other hand, as you observed, the internal phase feature for shelve was fairly established. It was functional with just a few ux bugs (list, patch). In my opinion, it's far better potentially to break the
archived
feature than the more stableinternal-phase
. I realize now I maybe should have started with proposing to makeinternal-phase
non-experimental before investing in it.Perhaps we could take this approach:
- Roll back
internal-phase-2
. - While
internal-phase
is still experimental, ifcleanup-as-archived
is enabled butinternal-phase
is not andexp-archived-phase
is not, warn that the user should disablecleanup-as-archived
or enableexp-archived-phase
. - Make
internal-phase
non-experimental. - After the warning above has had sufficient time to disseminate (1 yr?), enable
internal-phase
by default.
This approach would cause a lot less disruption for repos that have already adopted the
internal-phase
for shelves, including designs and rollouts around this feature.I acknowledge that my proposal isn't completely safe. Someone with an old repo in the right configuration could miss the warning and end up with
archived
activated unintentionally.What about if instead of (3) and (4), jump straight to enabling
internal-phase shelves
by default? That is, start honoring internal-phase shelves without the requirement. Would that be possible?The new name can be different if people have strong feelings about it, maybe
internal-phase-only
?phase-internal
?).Or maybe
internal-phase-shelves
orinternal-phase-proper
.For example, some config aliasing and some extra patches to automatically migrate the old requirement to the new one might be enough to ease the transition on your side. What do you think?
We can probably manage that. The biggest uncertainty is around repos that already inherited the
internal-phase
requirement. Since this requirement no longer exists, I suspect those repos will become invalid, so it'll be important to removeinternal-phase
and replace it withinternal-phase-{next}
. - Roll back