evolve: interaction with users running older mercurial versions

[Simon King]

On Fri, Dec 12, 2014 at 1:20 PM, Thomas De Schampheleire
<patrickdepinguin+mercurial at gmail.com> wrote:
> Hi,
>
> I would like to understand how the following scenario would end:
>
> 1. Alice has a recent Mercurial version and has enabled the evolve
> extension. She evolves one or more revisions in her repository so that
> one or more revisions are marked obsolete and replaced by new
> revisions.
>
> 2. Bob does not have evolve enabled and/or runs a Mercurial version
> that did not have full evolve support, and pulls from Alice's
> repository.
>
> What does Bob see in the pulled repository? Does he have a correct
> view of the current state, meaning that obsolete revisions are
> effectively obsolete and the final visible state is the one that Alice
> intended?
>
> In case it matters, with 'old Mercurial version' I am considering 2.6,
> I don't care about older versions.
>

Firstly, I think it is necessary to make a distinction between
obsolete changesets and hidden changesets. Mercurial has supported a
"hidden changeset" mechanism since at least 2.4. Hidden changesets are
suppressed from commands like "log" and "server". The "obsolete
changeset" mechanism is built on top of hidden changesets.

Secondly, I think it depends how Bob pulls from Alice's repository. If
the pull happens over the network (eg. ssh or http), and the version
of mercurial that is running on the server understands about obsolete
changesets, then it probably won't even serve those changesets to the
client, so it doesn't matter whether or not the client is older. If
Bob has direct access to the repository, then the capabilities of his
version of mercurial are more important.

I'm not sure what happens if the version on the server understands
about hidden changesets, but doesn't have the evolve extension
enabled. I *believe* it won't serve them, but I'm not certain.

Simon