Re: "cvs [commit aborted]: cannot commit files as 'root'"

[Greg A. Woods]

[ On Sunday, July 8, 2001 at 19:27:07 (-0400), Lenny Foner wrote: ]
> Subject: "cvs [commit aborted]: cannot commit files as 'root'"
>
> No, it only says that you can't.  It doesn't explain WHY, which was
> precisely the question that was asked.

Well of course not!  RTFM!

>  Nor, apparently, does it help
> anyone who ever gets it---they say, "Yeah, so, I'm root.  What's the
> big deal?"  And then (a) they waste their time asking the list, and
> (b) they waste all -our- time reading their question, and (c) they
> waste a few peoples' time who answer them.  Seems suboptimal to me...

You'll never eliminate "RTFM" answerable questions, not even if you put
the whole stinking manual right into the code so every message is as
verbose as humanly possible.

>     Maybe if it said "You, whomever you are, cannot commit files as 'root'!"
>     (complete with the explanation mark :-)
> 
> That doesn't help the users, whose immediate next question is, "why not?"

The immediate response of any sane person who asks such a question
should be to RTFM!
 
>     That's not a real suggestion though -- CVS error messages should remain
>     as stable as possible so as to facilitate ease of maintenance of wrapper
>     and front-end programs.
> 
> You're kidding, right?

Nope, not at all.   Not one iota.  That's a very very serious concern.
I dare you to write a front-end to CVS (as it is today) and say otherwise!

> You're actually arguing that error messages must remain fixed for all
> time because someone might have based a wrapper on them?

No, I'm not saying that either -- I'm saying they must not change
without due cause.

>  Whatever
> happened to the concept of exit codes?

What about them?  They serve an entirely separate purpose.

>  Whatever happened to the
> concept of the localization of all text emitted by a program for the
> user's native language?

What indeed!  Do you have patches to implement this feature in CVS?

>  Whatever happened to any pretense of design,
> not to mention professionalism?

You should learn some more about the history of CVS and its
development.  I'm sure such knowledge will enlighten you significantly!  ;-)

> If that's -really- the concern, then I submit that a much more stable
> mechanism would be to number all the error messages uniquely, and emit
> that number (perhaps surrounded by some sequence of characters not
> ever used elsewhere in error messages---though be careful of
> filenames!

This is a viable scheme, but it would take quite some doing to make CVS
(as we know it today) implement it.  UNIX System V took a similar
approach, though I don't know exactly how far they got.

> Sounds like sanity.sh should be amended to do a grep for every error
> message through the manual and at least make sure that it appears
> -somewhere-.

Hmm....  I think it would be easier to analyse the code and create REs
from the printf format strings....  At least then you know where the
variable bits of the messages are, and even what type of data to expect
in those places....

Such a tool would have much wider application than just CVS, of course!

>     Why?  What a waste of space, energy, resources, time, effort, etc.!
> 
> Because one implementor's effort saves n thousand people's time,
> that's why.

I think you vastly under-estimate the needs of the maintainer.  This is
no small problem we're talking about here!  I would submit that it
simply cannot ever succeed without at least partial automation, and of
course such a drastic change would require a very significant amount of
up-front work, even if one did draw upon existing practice (eg. have a
look at the code in Postfix).

I know of what I speak -- I've been around this block more than once
myself!

> Why force the user through an extra step?  He's already staring at the
> message.  Why not help him to understand what he's looking at?

Why force an expert user (not to mention a front-end driver program)
through all the extra verbiage?  Why not help the user learn to become
an expert user?

>     I really rather dislike execessive verbosity in error messages.
> 
> Is telling the user what he did wrong, and why, "excessive"?

Yes, absolutely.  A simple error number is insufficient except for the
most expert user (or front-end program).  An error message must give
just enough information to provide context and memory/search clues, and
absolutely no more.

We're not talking about some kind of fancy GUI-driven DWIM application
here!  If you want all that extra crud all the time then please put it
only int he fancy GUI DWIM thing, not in the underlying _tool_.

>  You
> sound like you're saying that all CVS error messages should simply be
> "?", like a certain well-known text editor from the early 70's, when
> memory was many cents/bit.  Or perhaps they should just be "abend 34117";
> after all, that's what the manual is for, right?

There was a significant UI advantage to that scheme, but of course it
can only be taken so far!  ;-)

> Inscrutible error messages may be -your- preference,

Now just hold on one minute here.  I _NEVER_ EVER said I wanted just a
'?' or even just an error number!!!!!  I want to be told what the error
is.  If I can't figure out why it occured then I'll RTFM!!!!!  Please
try to more carefully read what I write!

> What does this 90K cost us?

Let's assume that you're not measuring any of the important costs here!

> Keeping documentation up-to-date is often neglected.  Keeping the
> documentation in the code tends to make it more likely to be
> maintained.  Besides, it's obvious that the documentation wasn't kept
> up-to-date in this case anyway, so you can't exactly make an argument
> that it is in better shape than the code on this issue.

I won't disagree with you on either of those points.  I'd have an
entirely different approach to correcting them than you appear to have
though.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>