[darcs-devel] [issue2042] repair should be a subcommand of check

[Eric Kow]

I'm taking this off the tracker as it may open up into wider-ranging
discussion.

I've regrouped Guillaume's paragraphs into two themes, user-centric
and developer centric.

I think I need more persuading :-)

On Thu, Feb 10, 2011 at 12:48:14 +0000, gh wrote:

User centric
------------
> I suggest to make the repair command a subcommand of check, that should
> be invoked with "darcs check --repair".

Having separate commands seems useful if the two styles of command
require different flag sets.  You pointed out one issue below with
test (and all the test related flags, I'll mention)

I notice also that check has has --ignore-times, which repair does
not. Anybody know what's about?

> Conceptually, repairing something is a proper supertask of checking
> whether it is broken. Otherwise, how could you know what to repair?

I can see how repairing implies checking.

Asking from a UI principles standpoint, if task R a proper supertask
of task C; should R be treated as an flag to C?

Asking from a UI consistency standpoint, what do we currently do?  Is it
appropriate to consider darcs get/init as another R/C pair, or does the
analogy not hold (eg. because init is a trivial blip the total lifespan
of get, whereas repair is essentially an afterthought to check?)

From a principles standpoint, are we confusing developer mental model
for user mental model?  As a user, should I even care that repairing
is just check plus a smidgen extra work?  How would does (knowing I
have to run)

   darcs check
   darcs check --repair

Make darcs any better to use?
 
> Making repair an option of check would only involve making sure tests
> are not run (ie, --repair should imply --no-test).

> And "darcs repair" should be added as an alias for "darcs check --repair".

Developer centric
-----------------
> When it comes to the current darcs code, modules Darcs.Command.Check and
> Darcs.Command.Repair have a lot of overlap, and Darcs.Commands.Repair is
> quite small (without the boilerplate).
>
> This change would also get rid of the module Darcs.Command.Repair, for
> the greatest cognitive relief of current and future darcs developers. :-)

Heh, presumably we want to avoid making UI decisions on the basis of
developer convenience.

There must be alternative solutions for reducing the overlap, no?


-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
For a faster response, try +44 (0)1273 64 2905 or
xmpp:kowey at jabber.fr (Jabber or Google Talk only)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.osuosl.org/pipermail/darcs-devel/attachments/20110217/4771f415/attachment.asc>