As the tests added by the previous changeset demonstrate, stream clones
were never taught about the existence of phases. As a result, all
changesets applied via stream clone were made public, even if they
were draft (or even secret) on the remote.
This commit integrates phases knowledge into stream clones.
As the inline comment explains, because there are scenarios where
we can't disambiguate phases support, the resulting phase data may
not match the server exactly. However, I believe the remaining
areas of buggy behavior are confined to secret changesets. Secret
changesets aren't common. And transferring them via stream clones
either requires a buggy Mercurial server or a specially-configured
server. I think it will require stream clone support in bundle2
before we can properly handle secret phases for stream clones.
It /might/ be acceptable to force all local changesets to secret
and then promote to draft or public from remote phases data. However,
I was having trouble implementing this. Existing phases code doesn't
seem geared towards supporting this scenario and I didn't want to
incur a lot of extra work to refactor the phases code. Perfect is
the enemy of good: I'm inclined to tackle secret phase as part of
supporting stream clones in bundle2.
This change introduces a roots(all()) revset, which will require
a linear scan of the changelog during clone bundles. On a Firefox
repo, this may slow down stream clones by ~1s. Again, support for
stream clones in bundle2 should help here.
.. fix::
Draft changeset phase is now preserved during a stream clone. Before, all changesets pulled via a stream clone would have a public phase, even if they were draft on the remote and the remote was non-publishing.
Shouldn't we test remotephases.get('publishing', False) for
mixed-phase + publishing server?