[MERGE][BUG #153786] Autopack retries
mbp at canonical.com
Wed Dec 17 01:24:30 GMT 2008
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
> 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
> 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.
> +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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20081217/cf2ae4fc/attachment.pgp
More information about the bazaar