Differences between revisions 1 and 3 (spanning 2 versions)
Revision 1 as of 2019-10-09 23:48:56
Size: 2887
Comment:
Revision 3 as of 2020-09-15 16:41:04
Size: 2917
Comment:
Deletions are marked like this. Additions are marked like this.
Line 9: Line 9:
'''Main proponents: Pierre-YvesDavid''' '''Main proponents: [[Pierre-YvesDavid]]'''
Line 13: Line 13:
Shares does not shares some critical component with their source, leading to various important bugs. The should fix them behind a `safeshare` requirements Shares do not share some critical pieces of data with their source, leading to various important bugs. We should fix that by adding a `safeshare` requirements.
Line 19: Line 19:
* shares does not read the source repository config this become a large issues for: * shares do not read the source repository's config, which becomes a large issues for:
Line 25: Line 25:
* shares does not read the source repository `requires` file. This lead to the share possibly missing important format upgrade from their source. * shares do not read the source repository's `requires` file. This leads to the share possibly missing important format upgrades from their source.
Line 35: Line 35:
Right now, shares copy the requirements at share time and never read them from source again. This mean shares will lag behind if the source repository is updated. This can have serious consequences (eg: repo corruption, bypassed hooks). To avoid this, the share should use the source requirements as the source of truth. However, some requirements are working copy specific. For such requirements, reading them from the source is meaningless and we need to still be able to add them on the share. Right now, shares copy the requirements at share time and never read them from source again. This mean shares will lag behind if the source repository is updated. This can have serious consequences (eg: repo corruption, bypassed hooks). To avoid this, the share should use the source requirements as the source of truth. However, some requirements are working copy specific (e.g. `sparse`). For such requirements, reading them from the source is meaningless and we need to still be able to add them on the share.

Note:

This page is primarily intended for developers of Mercurial.

Share Share Plan

Status: Project

Main proponents: Pierre-YvesDavid

/!\ This is a speculative project and does not represent any firm decisions on future behavior.

Shares do not share some critical pieces of data with their source, leading to various important bugs. We should fix that by adding a safeshare requirements.

1. Goal

There are currently some important bugs:

* shares do not read the source repository's config, which becomes a large issues for:

  • hooks
  • storage/format configuration
  • behavior impacting config (eg: phase.publishing)

  • behavior impacting extension

* shares do not read the source repository's requires file. This leads to the share possibly missing important format upgrades from their source.

The solution would be to introduce a new sharesafe requirement that fix both the config and requirement needs

2. Detailed description

To make sure older version cannot create shares from safe repo, we introduce a new sharesafe requirements. New behavior will be gated behind it.

2.1. requirements

Right now, shares copy the requirements at share time and never read them from source again. This mean shares will lag behind if the source repository is updated. This can have serious consequences (eg: repo corruption, bypassed hooks). To avoid this, the share should use the source requirements as the source of truth. However, some requirements are working copy specific (e.g. sparse). For such requirements, reading them from the source is meaningless and we need to still be able to add them on the share.

The best option seems to move the default location for requirements in .hg/store/requires and to explicitly flag the working copy specific ones. The sharesafe requirement needs to also lives in .hg/requires to fend off older clients.

2.2. config

The current behavior prevent hooks and other information to be propagated to shares. This can lead to very serious issues. For this reason, it seems "reasonable" to /!\ break backward compatibility /!\ and have shares read the source .hg/hgrc by default. For case that requires non-shared config, a new .hg/nonsharedrc is to be introduced.

3. Roadmap

  • introduce a exp-sharesafe requirement to test the new code {X} controlled by a format.exp-share-safe config

  • move appropriate requirements under .hg/store/requires (if sharesafe) {X}

  • have share also read the source repository path {X}

  • introduces a .hg/nonsharedrc read after the .hg/hgrc {X} (with ass associated flag for hg config)

  • get shares to also read .hg/hgrc (if sharesafe) {X}

  • rename exp-sharesafe and config requirement {X}

4. See Also


CategoryDeveloper CategoryNewFeatures

ShareSafePlan (last edited 2020-09-16 08:16:06 by PulkitGoyal)