Suggestion re failed CVS updates

["BAZLEY, Sebastian" <Se...@london.sema.slb.com>]

There seem to be quite a few failed CVS updates at the moment for some of
the non-Apache repositories.
As these (by definition, I suppose) are for dependencies relied on by other
projects, these failures can have a big knock-on effect.

Would it be possible to treat CVS errors as non-fatal?
This would have the same effect as if there had been no changes in CVS.

The build should allowed to continue on that basis that it might depend on
something else that _had_ changed. The problem would need to be flagged
against the individual project.

Other projects would still be able to be built against the latest
"available" sources, for at least some sense of available.

Just a thought.

-- 
Sebastian Bazley 

Re: Suggestion re failed CVS updates

["Adam R. B. Jack" <aj...@trysybase.com>]

I've changed:

    log.error('Failed to checkout/update module: ' + module.name)
    module.changeState(STATE_FAILED,REASON_UPDATE_FAILED)

to the following. It's an update not a checkout if 'exists' evaluates to
true. The 'changeState' on a module will propagate an error to all children
(projects) and a project will propagate it to all (non-optional) dependees.
As such, we are now logging it (in various places) and then settign this
wierd -- "success but ..." state.

    log.error('Failed to checkout/update module: ' + module.name)
    if not exists:
        module.changeState(STATE_FAILED,REASON_UPDATE_FAILED)
    else:
        module.addError('*** Failed to update from source control. Stale
contents ***')
        # Black mark for this repository
        repository=module.getRepository()
        repository.addError('*** Failed to update %s from source control.
Stale contents ***' \
                    % module.getName())
        # Kinda bogus, but better than nowt (for now)
        module.changeState(STATE_SUCCESS,REASON_UPDATE_FAILED)

When I get more time I'll modify the statistics for the repository, and keep
track of such failures.

regards,

Adam

Re: Suggestion re failed CVS updates

["Adam R. B. Jack" <aj...@trysybase.com>]

>
> > Would it be possible to treat CVS errors as non-fatal?
>
> The "traditional" Gump should do exactly as you expect - if it has
> been able to perfom a CVS checkout at least once, that is.

This thought occurred to me as (this weekend) I couldn't test crap due to
cvs.SF.net dumping on junit.

What I'll do is mark a warning, but continue. Better some Gumping than none
when CVS/SVN updates fail.

I just want reader of the Gump output to be very aware that this occurred,
and the Gump is potentially on stale data.

Folks like SF.net have show we can have 'extended outages' with Gump runs
giving folks a false sense of security.

regards,

Adam

Re: Suggestion re failed CVS updates

[Stefan Bodewig <bo...@apache.org>]

On Mon, 08 Dec 2003, Sebastian BAZLEY
<Se...@london.sema.slb.com> wrote:

> Would it be possible to treat CVS errors as non-fatal?

Are you talking about the LSD Gump runs?

The "traditional" Gump should do exactly as you expect - if it has
been able to perfom a CVS checkout at least once, that is.

Stefan