This is an archive of the discontinued Mercurial Phabricator instance.

upgrade_utils: add support for enabling internal phases during upgrade
AbandonedPublic

Authored by Mathiasdm on Jun 28 2021, 8:44 AM.

Details

Reviewers
None
Group Reviewers
hg-reviewers
Summary

This makes it possible to start using internal and archived phases
on an existing repository,
if the following is set in the configuration:

[format]
internal-phase=yes

Diff Detail

Repository
rHG Mercurial
Branch
default
Lint
No Linters Available
Unit
No Unit Test Coverage

Event Timeline

Mathiasdm created this revision.Jun 28 2021, 8:44 AM
Mathiasdm abandoned this revision.Jun 28 2021, 9:55 AM

Retracting this one, I notice some test failures I need to have a look at.

Retracting this one, I notice some test failures I need to have a look at.

beware that the feature is not ready for prime time as some remaining issue/question needs to be solved/answered, most notably its interraction with distributed obsolescence. I remember doing a write up about this for the sprint last november but I cannot find it.

It would indeed be interesting to see that writeup. This is the feature we miss the most to be able to enable obsolescence for all our users.
Regarding this change itself: I figured it would not harm to add upgrade-support, as it only becomes visible when the experimental parameter has been set.

It would indeed be interesting to see that writeup. This is the feature we miss the most to be able to enable obsolescence for all our users.
Regarding this change itself: I figured it would not harm to add upgrade-support, as it only becomes visible when the experimental parameter has been set.

How is this related to "enable obsolescence to all users ?"

If obsolescence is enabled, the behaviour of 'strip' is not ideal. What users typically want is the behaviour of 'hg strip --soft', as the regular 'hg strip' makes older revisions visible again.

marmoute added a comment.EditedJun 28 2021, 10:49 AM

If obsolescence is enabled, the behaviour of 'strip' is not ideal. What users typically want is the behaviour of 'hg strip --soft', as the regular 'hg strip' makes older revisions visible again.

Which is exactly the kind of behavior with hg strip --soft that will cause probleme with evolution :-D

It looks like your users wants hg prune, do they not ?

It sounded to me like 'hg prune' and 'hg strip --soft' both covered the same use case.

The main benefit to me seemed that 'hg strip --soft' doesn't require me to enable evolve for all our users. I would like to have obsolescence markers for all our users, but without a properly working 'hg strip', that wasn't possible.

Mathiasdm edited the summary of this revision. (Show Details)Jun 28 2021, 11:17 AM
Mathiasdm updated this revision to Diff 28703.

It sounded to me like 'hg prune' and 'hg strip --soft' both covered the same use case.
The main benefit to me seemed that 'hg strip --soft' doesn't require me to enable evolve for all our users.

What are you trying to achive with hg strip --soft that you cannot achieve with evolve. And what are the things blokcing you from enabling evolution for all your users ?

I would like to have obsolescence markers for all our users, but without a properly working 'hg strip', that wasn't possible.

hg strip is properly working. It is doing exactly what it is documented to do :-)

hg strip --soft with evolution -is- not properly working as it is going to hide content, without hiding the associated obsmarkers, leading to indecipherable situation for users. So mixing the two is not the way to go (and one of the reason the feature is still experimental).

It sounded to me like 'hg prune' and 'hg strip --soft' both covered the same use case.
The main benefit to me seemed that 'hg strip --soft' doesn't require me to enable evolve for all our users.

What are you trying to achive with hg strip --soft that you cannot achieve with evolve. And what are the things blokcing you from enabling evolution for all your users ?

We can achieve everything with evolve, but that requires that we provide evolve everywhere and make sure it's in line with the Mercurial version used.
If evolve (or the 'hg prune' part) was shipped with Mercurial, we would probably have it enabled already.

I know that sounds like we just need to get our infrastructure set up to handle this properly (and to some degree, that's correct), but for us, it's just additional hoops to jump through, and more parts of the infrastructure that need to be synced with each other.

(If you like, we can have a call to discuss further.)

I would like to have obsolescence markers for all our users, but without a properly working 'hg strip', that wasn't possible.

hg strip is properly working. It is doing exactly what it is documented to do :-)

Agreed, but it's somewhat confusing for our users.

hg strip --soft with evolution -is- not properly working as it is going to hide content, without hiding the associated obsmarkers, leading to indecipherable situation for users. So mixing the two is not the way to go (and one of the reason the feature is still experimental).

Ok, that makes sense, thanks for clarifying.

Mathiasdm abandoned this revision.Jul 2 2021, 2:18 AM

Closing this one then.