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

[marmoute (Pierre-Yves David)]

marmoute added a comment.


  In D8480#127657 <https://phab.mercurial-scm.org/D8480#127657>, @durin42 wrote:
  
  > This patch is contentious, but I'm a little unclear why. Summarizing so everyone at least parses my thoughts roughly the way I mean: mandatory parts mean "fail if you can't process this part." It seems basically reasonable to me that a client can choose to ignore (perhaps through ignorance) obsolete markers and it'll be potentially confusing, but not /wrong/ in that they'll have the changesets they expected, but also didn't lose some the server thought they would. It feels like a bug if a client requests obsmarkers and then discards them?
  
  I guess the misundestanding is here. Not exchanching markers when we should give **wrong** result and user activelly complains and report bugs then it happens to them. Hooks and checks can also get confused by the broken end-state this creates.
  
  > But in the case of any kind of pre-computed bundle it's a little trickier because if the server (as an optimization, in this case) emits obsmarkers that the client didn't request, it could break old clients.
  
  In the case of precomputed bundled explicitly used as cache (pull bundle/clone bundke9, having the markers optional seems fine since the client will performs a full pull afterward, pull markers they might have missed earlier. My proposal of having a bundlespec option for this case `hg bundle -t v2;obsolescence=optional` should be covering that case, unless I am missing something.
  
  In the other case of people using bundles to exchange data (eg: by email or with USB dongle). Making the part optionnal can lead to people not exchanging what they want, leading to wrong result, confusion and bug report/perception.
  
  > Given that obsmarkers are still off by default and effectively experimental, we can change whatever we want. So the question is: should we, and if so, should it be all obsmarker parts or only precomputed ones? I think it's pretty clear that we should at least allow optional obsmarker parts for precomputed bundles, and I think we also should allow mandatory obsmarker parts (so if you try to push markers to a server that doesn't grok them you get an error instead of ninja-duplicating some changesets with their evolved counterparts.)
  > So that leaves us with the one remaining question: what should the server do when the client proactively requests markers? I think in that case it basically doesn't matter, so either way is fine. If it's less work, I'm inclined to land the patch as-is, and we can do a follow-up if there's a bug case that I'm not understanding today.
  
  I don't undestand your point here. If a client request obsmarkers and does not  (effectively) receive them, the result if wrong, the end state can ge broken, user get confused and report/percieve bugs.

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://mercurial-scm.org/pipermail/mercurial-patches/attachments/20200602/b9fe0135/attachment.html>