[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Greg A. Woods
Subject: Re: "cvs [commit aborted]: cannot commit files as 'root'"
Date: Sun, 8 Jul 2001 18:28:50 -0400 (EDT)

[ On Sunday, July 8, 2001 at 16:00:55 (-0400), Lenny Foner wrote: ]
> Subject: "cvs [commit aborted]: cannot commit files as 'root'"
> You know, given how often people ask this question, maybe some
> paragraph of your response here should be put INTO THE ERROR

Well actually I would have thought the message was already very very
clear all by itself -- if maybe a bit terse for anyone with English as a
second language.  It does, after all, say exactly what it means.

Maybe if it said "You, whomever you are, cannot commit files as 'root'!"
(complete with the explanation mark :-)

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.

I think what maybe surprises people about this is that usually 'root'
can do anything and usually error messages say "you must be root to...."
Obviously though a source code control system has different security
requirements than a filesystem.

> Yeah, I know, I know, everyone will say "that's why you're supposed
> to read the manual!", but it's obvious that either (a) people aren't
> reading it well enough, or (b) it's a little too buried.

It isn't even in the manual, as far as I can see.  That's maybe the
worst failing of the manual -- there's no (even partial) list of the
error messages in one place with links to nodes containing their

> My basic point here is that, industry-wide, far too many error
> messages are far too terse.  They should include paragraphs of prose,
> pointers to manual sections, URLs for further clarification---and
> probably all -three- of them.  Why not?

Why?  What a waste of space, energy, resources, time, effort, etc.!

All that's really necessary is that the documentation contain
descriptions of the error messages.  With 'info' documentation the
searching for the meaning is extremely simple.

I really rather dislike execessive verbosity in error messages.

Specifically for CVS though error messages should be kept as stable as
possible and short enough that when fully formatted with an average
filename they don't exceed 80 characters in length.

>  After all, we're no longer
> using 300 baud teletypes where a long error message takes a minute to
> sit through.  Nor does it matter if the executable is 10K larger
> because the error messages actually tell you what's wrong---not in an
> era of 1G OS's and 10M applications...

Size and speed aren't everything (though they're certainly still very
very important -- far more important than you seem to think!).

Maintenance is also incredibly important.  I think it's far better to
have very good documentation and to keep it up-to-date with lists and
descriptions of error messages rather than to have to maintain the same
text in both the code and the documentation (or come up with some
convoluted scheme to try to merge one from the other).

                                                        Greg A. Woods

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]