Re: [PATCH] pull: gracefully recover from delta retrieval failure.

quoted

quoted

quoted

quoted

"JM" == Jason McMullan [off-list ref] writes:

JM> Sorry about being a pest, but this worries me. Please assuage my fears.

Earlier I said I suspected that the original code mishandled
recovery from a botched tree/commit dependent transfer, but that
was not the case.  The last test in the new test script I added
in the patch you are responding to covers that case.

JM> (Or, if you'd like, I can rework pull.c to use the
JM>  verification-before-store technique I used in my git-daemon patch, so
JM>  all the *-pull mechanisms will be 'safe')

I would appreciate the offer.  I, however, would have to warn
you that the "problem" lies in the way the current pull
structure devides responsibility between the pull.c and transfer
backends.  The pull.c implements the dependency logic, and
transfer backends are to populate the database while being
oblivious of that logic.  From the purist point of view (I am
sympathetic to your "place only the verified objects in the
database" principle), I am not entirely happy with that
division, but at the same time I understand why it is done that
way and even like it from practical standpoint.  Otherwise you
need to keep a bunch of objects somewhere outside the database
along with the list of "things to rename to the final database
name when we are done".  You would somehow need to do clean-up
when we fail in the middle _anyway_.

In other words, the current structure is optimized for non-
failure case, as it should be.  The original implementation
(credit goes to Dan Barkalow) knew how to recover from failed
transfer (including the case that you first pull with -c or -t
without using -a to miss some required objects to satisfy -a) by
simply running pull again, and with the --recover flag, it now
knows how to recover from failed deltified object transfer as
well.