Public SourceMage Discussion List

["Jeremy Blosser (emrys)" <jblosser-smgl AT firinn.org>]

On Sep 26, Andrew [afrayedknot AT thefrayedknot.armory.com] wrote:
> Stable sorcery did not check the return code, it assumes cvs always works.
> Thats a bug. That and several other things were what prompted the major
> re-factoring of download code.
> 
> Im open to suggestions on a better compromise behavior for failed scm
> checkouts.

I guess the more complicated thing to do would look like:

- preexisting scm checkout spool tarball is available?
  - Y: attempt to update
    - update succeeded?
      - Y: create new spool tarball
      - N: abandon any partial update, revert back to preexisting tarball
  - N: attempt initial checkout
    - checkout succeeded?
      - Y: create spool tarball
      - N: die

The case where it fails the update and we revert back to an existing
tarball probably would need to ask the user what to do next*.  The source
hasn't changed at all but maybe they want/need to do a rebuild of what they
have anyway.

(*It may do this now, I haven't seen a failed cvs update on test sorcery in
practice yet.)

> However, hropping the exit code on the floor is absolutely the wrong
> thing to do. That people think thats someone "okay" is quite distressing.
> 
> On the other point:
> 
> It might be worthwhile to not look at fallback mirrors for non-tarball
> downloads.

I think we'd only look at our own fallback mirrors if we were committing to
keep tarballs on them and update them on a semi-regular basis.  This is
feasible technically but may not be feasible with the resources we have
available, I don't know.

Attachment: pgpAwWP9Iafzf.pgp
Description: PGP signature