RFC: check UI

[Vincent Ladeuil]

>>>>> "robert" == Robert Collins <robert.collins at canonical.com> writes:

<snip/>

    robert> OTOH you can't tell if a branch is correct without
    robert> reading a bunch of repo data; (is the revision cached
    robert> value correct? Do the tags exist etc).

Sure. The use case was 'check -all', ok, problems in branch, try
some stuff, 'check --branch;, rinse, repeat, finally 'check all'.

    robert> If its a few minutes on even very large repositories
    robert> would you really care?

Surely not... if it's < 10 :-)

    robert> I guess the answer is yes, but perhaps a 'skip-FOO'
    robert> style of option would be clearer than the current
    robert> ones?

Whatever, as long as they are boolean options we can use a '-no-'
prefix.

I see 'check' as a very strong validator, so I don't mind it
being slow if it means keeping the code easy to read and maintain
and *rock solid* (emphasis on the ability to continue checking
even if bad errors occur). Not stupidly slow of course, but I
don't want it to take short-cuts either if it means *some* errors
can go unnoticed.

But doing a thorough check doesn't have to be the default mode
(not sure though), as long as the cheks are layered and the
layers can be controlled via options. We have tree, branch repo,
we can have graph, revisions, text, signatures, tags, whatever.

It if means check is slow because we do n passes to do n checks
instead of a single pass, I'll go for that if it makes the code
simpler and more robust.

And I don't care if check accept a gazillion options as long as a
casual user doesn't need to understand them (I.e. the help can
start with "You don't need to understand all the options just use
'bzr check --blah" unless told otherwise").

    >> I'm not sure DWIM is worth the effort here...
    >> 
    >> A related point: I've been bitten in the past because I forgotten
    >> to specify '-v' for a repo check that took day(s). So I'd like
    >> check to *always* output data that may be needed to fix whatever
    >> is found to be wrong (putting that info in .bzr.log is ok).

    robert> For sure.

Great,
        Vincent