[Top][All Lists]

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

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

From: Lenny Foner
Subject: "cvs [commit aborted]: cannot commit files as 'root'"
Date: Sun, 8 Jul 2001 16:00:55 -0400 (EDT)

    Date: Sun, 8 Jul 2001 15:26:59 -0400 (EDT)
    From: address@hidden (Larry Jones)

    Matthew Von-Maszewski writes:
    > cvs [commit aborted]: cannot commit files as 'root'
    > Is this an intended security feature ... or am I just being stupid again?

    It's an intended feature, but it has more to do with maintaining
    accountability than security.  Since root is usually a shared account,
    CVS won't allow you to commit as root unless it can figure out who you
    really are.  Logging in as yourself and then su'ing to root will usually
    allow CVS to figure out who you are, logging in as root won't.  If
    you're sure you want to be able to commit as root, see CVS_BADROOT in

You know, given how often people ask this question, maybe some
paragraph of your response here should be put INTO THE ERROR

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.

So why not actually spell the entire thing out in the message?  It's
not like brevity is required in these things.  I'd say you should just
take everything after the first sentence above (e.g., starting at
"Since root is usually...") and just add it to the error message.

If that were done, some large percentage of FAQs would stop being

If that were done to many of the other common screwups, many more
people could also be instantly enlightened, instead of asking the
list.  It speeds them up (they don't have to (a) try to find the
message in th emanual, or (b) compose a message, send it, and wait for
a reply), and it might even make life easier for people who are using
CVS whose native language isn't English and who aren't using some
localized copy---after all, the more explanation there is, the more
likely that some subportion of it will be intelligible enough that the
user will understand it.  [My favorite example of this---and it's even
for a native English speaker!---is the compiler error message saying
"FOO is multiply defined", which invariably causes some subset of
those reading it to say, "What in the world does multiplication have
to do with what I"m doing?"  It -should- say, "FOO is defined more
than once" or "FOO is defined multiple times"---just a teeny bit of
additional prose can do wonders.]

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?  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...

Thanks for listening...

reply via email to

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