This revision is now accepted and ready to land. durin42 added a comment. durin42 accepted this revision.
In D7972#120504 <https://phab.mercurial-scm.org/D7972#120504>, @valentin.gatienbaron wrote: >> I _think_ it's just paranoia. As long as the bundle wasn't woefully corrupt, it shouldn't be a problem. I _think_ if we set some of the [server]-section bundle validation options (which should be cheap enough) we could ditch this completely safely. >> As it stands, I'm fine with this patch if someone else has the confidence to push it. > > How does the validity of an input bundle affect recover? It could have borked linknodes or missing filenodes. That can happen in some cases with subtle revlog corruption. Back when I helped run code.google.com we saw a few cases of that, where clients couldn't push specific changes unless they pushed their whole repo. But anyway, I was mis-thinking about this and this is about `hg recover` and not recovering something from a backup bundle (sigh) so we've been talking past each other. > I would have thought it's only the validity of the journal that matters, and that's created entirely based on local data (file lengths or contents before writes). Yes, you're right. > Now I suppose the journal itself may well be truncated or not written at all when running out of disk space or other error situations where the OS does the writes out of order. Yeah, it's possible on a network FS or something, but this honeslty seems like a safe change to me. Sorry I misread it last time through. :/ REPOSITORY rHG Mercurial BRANCH default CHANGES SINCE LAST ACTION https://phab.mercurial-scm.org/D7972/new/ REVISION DETAIL https://phab.mercurial-scm.org/D7972 To: valentin.gatienbaron, #hg-reviewers, marmoute, durin42 Cc: durin42, marmoute, pulkit, mjpieters, mercurial-devel _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
