lothiraldan added a comment.
In https://phab.mercurial-scm.org/D3694#58242, @durin42 wrote:
> In https://phab.mercurial-scm.org/D3694#58241, @lothiraldan wrote:
> > > Interesting. I think I like this, it's a bummer that it requires a
format bump in requires.
> > - There are no format changes per-se, older client would preserve the
phases for internal changesets, but have them visible,
> We didn't do a format bump when we introduced draft/secret phases, so maybe
we should punt here too.
Phases did not introduce any regression in behavior. When draft/secret where
introduced, older clients could keep interacting with the repository the same
way as before. The new changesets created by new clients were seen just fine
(but not the associated behavior).
However in the shelve case, if both a new client and an old client access the
same local repository, we have a change in behavior:
- before: shelve created from the new client are stripped and invisible to
the old client
- after: shelve created from the new client are visible as changeset to the
The danger is that users could push those intermediary shelve commits if they
are not careful. The new requirements and the error message will make them
think about the issue and not push intermediary commits.
>> - This is also something we would need for obsshelve (non evolve enabled
client complaining about markers),
> I don't think so, because in general shelve isn't being run on a repository
that's accessed remotely. (In general - that's not always true, but I think
it's "true enough" esp. since we _need_ to ship obsmarkers on by default soon.)
We have the same scenario for obsshelve:
- before: shelve created from the new client are stripped
- after: shelve created from the new client create obsmarkers and trigger
This is not a theoretical case, we have seen valid situations where new and
old client access the same repositories.
>> - There are more format bumps coming (when solving issue5480) and to other
>>> I'm a little anxious about defining the `internal` phase because it might
restrict the potential for other phases past secret
>> I kept things simple in the current series, but I had a similar thinking.
One option is to encode the internal phase as "32" instead of "3" to leave us
room for other phases. If we this we need to update the implementation with one
of the following:
>> (1) add 29 "reserved" empty phase that will remain empty.
>> (2) rework the phases touching code to work on non-contiguous numbers.
> How much work is this, do you have any idea?
The first option (adding "reserved" phase) should be very quick to implement.
It might need minor adjustment for performance but I don't expect many.
The second option (changing all algorithm to handle the gap) is more work
since about all algorithm touching phases in Core and extensions assume they
can be handled as a simple list.
So I would pick the first option.
To: lothiraldan, #hg-reviewers
Cc: durin42, mercurial-devel
Mercurial-devel mailing list