[MERGE][BUG #153786] Autopack retries

[Martin Pool]

On 16 Dec 2008, John Arbash Meinel <john at arbash-meinel.com> wrote:
> This is another step in the "get pack actions to retry when pack files
> move."
> 
> In this case, I only worked on supporting "autopack" functionality. With
> the basic result that if the pack files change, we start from scratch.
> For "autopack" this seems perfectly fine, because most likely this is
> caused by someone else actually completing an autopack while we are
> trying to do our own.
> 
> I was originally thinking to make it more generic, so that any Packer
> based fetch would work. But I feel like we are moving towards the
> "get_record_stream()" api anyway, which I already gave the ability to
> restart.
> 
> I had been working on having Packer not start from scratch each time,
> and that gets hard to figure out exactly what needs to be copied, what
> has already been copied, and where the new data should be put. (Start a
> new pack, try to append to the existing one, etc.)
> 
> Anyway, this is still better than what we had, because it will allow
> concurrent autopacks to succeed.

That looks good.

BB: tweak

> +class RetryAutopack(RetryWithNewPacks):
> +    """Raised when we are autopacking and we find a missing file.
> +
> +    Meant as a signaling exception, to tell the autopack code it should try
> +    again.
> +    """
> +
> +    internal_error = True
> +
> +    _fmt = ("Pack files have changed, reload and try autopack again.")
> +
> +

In general exceptions should include some clue to where they occurred,
like the url of the repository or the exception that initiated it.  If
the error occurs in a bug report or is hard to reproduce it gives us
somewhere to start from.

Does this need to be a separate error from RetryWithNewPacks?

-- 
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20081217/cf2ae4fc/attachment.pgp