[Commented On] D8480: bundle2: make obsolescence parts optional

marmoute (Pierre-Yves David) phabricator at mercurial-scm.org
Thu May 7 09:10:03 UTC 2020


marmoute added a comment.


  TL;DR; We should add a third value to the bundlespec argument: `hg bundle -t v2;obsolescence=optional`
  
  about part in general
  ---------------------
  
  Parts that are mandatory are parts that most be processed for the request (eg: push) or reply (eg: pull) to correct. Such parts are either verification steps or core payload that contains the content that was requested to be transfered.
  
  Advisory parts carries information that will helps the applying side, but can be ignored without compromising the "result" of the bundle application.
  
  about push/pull
  ---------------
  
  Most exchanges happens through push and pull in these cases the two peers can negociate contents and capabilities, and the bundling side knows: (1) what is is requested to be exchanged (2) what the receiving side is expected to support.  Requested content (eg: changesets, phases, obsmarkers) are sent in mandatory parts, because failure to transfer them would mean the failure of the exchange.  The same a push not sending the changeset it should should be a failure, a push not sending the markers it should, should be a failure. Not sending markers result in changeset not being obsoleted and uter confusion for the user.
  
  So the markers must be sent in a mandatory part during push/pull (same as the other important payload). If the receiving peer get a part version it does not understant, there is a bug, and it should bark.
  
  about offline bundle
  --------------------
  
  The case of offline bundle is a bit tricker. Two people might be exchanging data on purpose, expecting the obsmarker to be exchanged, or we can be in a blind case were data is pre-generated for all.
  
  In the first case, we want the part to be mandatory, because the users wants the markers to be exchanges. In the second case, the server operator only want a best effort approach were users who do not care about the markers should not take them.
  
  Possible way forward.
  ---------------------
  
  We already have a bundlespec argument to control obsmarkers inclusion:
  
    hg bundle -t v2;obsolescence=yes  # with obsmarker
    hg bundle -t v2;obsolescence=no   # without obsmarkers
  
  It seems simple to add a third value, to include them as advisory:
  
    hg bundle -t v2;obsolescence=optional   # without obsmarkers
  
  Server operator could that option to pregenerate bundles.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D8480/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D8480

To: joerg.sonnenberger, #hg-reviewers, marmoute
Cc: durin42, marmoute, mercurial-patches
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-patches/attachments/20200507/b2291d4b/attachment-0002.html>


More information about the Mercurial-patches mailing list