5

I currently work for a company that uses mercurial, but most developers use MQ instead of the new evolve flow. Therefore, most users do not have the extension enabled.

Every time I push to the main repository, .hg/store/obsstore gets automatically pushed with the obsolete changesets. This is problematic because after that all users that do not have the extension enabled get the following message:

obsolete feature not enabled but 33 markers found!

One solution, proposed in this answer, involves deleting .obsstore locally, but that's not what I want, since I'm still working with evolve and that means I expect the obsolete changesets to remain hidden. Not only that, but obsolete markers and changesets should be available on the server repo so that we keep the benefits of using evolve such as intelligent conflict solving.

I'd expect a way to either not push the obsolete changesets to the server repo, or (the correct way) for the server to not push the obsolete data to clients without evolve enabled.

Is this possible? If not, why not?

Euller Borges
  • 91
  • 7
  • 1
    This post does not answer your question, but it is worth reading: [Please Stop Using MQ](https://gregoryszorc.com/blog/2014/06/23/please-stop-using-mq/) – andref Jun 11 '18 at 03:15
  • Thank you, @andref. I had already read that entry, it makes very good points on why not to use MQ. Unfortunately, most people where I work do not agree, simply because there's a curve to learning a new paradigm. – Euller Borges Jun 20 '18 at 12:08
  • @EullerBorges was evolve enabled on your server? – melutovich Apr 18 '23 at 13:34

2 Answers2

2

If you really want to use evolve locally but not exchange your obsmarkers, you can do it. I will tell you how but be aware that you will have the exact same set of problems as with using stripping and rebase without evolve. If you push a previous version of a changeset and pushed the new version, the server will have the two versions at the same time. If you want to use Evolve only locally you can add these lines in your config files:

[experimental]
createmarkers=True
allowunstable=True
exchangeopt=False
Boris Feld
  • 825
  • 7
  • 8
  • This, unfortunately does not solve the issue. The obsolescence markers are still pushed upstream with this configuration. I think this is a major setback for evolve, since this means I have to manually delete obspurge every time (otherwise the tool is pretty much broken for other users). – Euller Borges Jun 20 '18 at 12:05
2

I found a couple of workarounds (hacks) to this problem, since it looks like mercurial has no way to solve this issue as of the writing of this answer:

Per-repository evolve extension

Remove the evolve extension from the ~/.hgrc file, enable it on a per-repository basis, and then use SSH to point to the repository (in our case it is on NFS, which is the source of the problem).

That is, on your repository's hgrc you'd have:

# This is <repo>/.hg/hgrc
[paths]
default = ssh://localhost//path/to/origin/repo
[extensions]
evolve =

and on ~/.hgrc:

[extensions]
# evolve =     => Disabled on purpose

Removing obsolete markers using hooks

Just use a hook to remove the .obspurge file on your repository's hgrc:

# This is <repo>/.hg/hgrc
[alias]
obspurge = !echo "Purging obsolete markers" && rm /path/to/origin/repo/.hg/store/obsstore
[hooks]
post-push = hg obspurge
Euller Borges
  • 91
  • 7