[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Suggestion: "svn explain"

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2002-08-03 19:46:37 CEST

Well, I'm against "svn explain", partly because I think we should stop
reporting error codes at all. Our error messages are much too verbose.
An example error:

  svn_error: #21079 : <Item already exists in filesystem>
    file `file:///var/ghudson/svn-test/grows' already exists.

Aside from being visually ugly with the leading newline, an unschooled
reader is likely to get caught up in the cryptic "svn_error: #21044 : <
...>" and take more time to get to the important text. I would display
this as, perhaps:

  svn: Item already exists in filesystem
  svn: file `file:///var/ghudson/svn-test/grows' already exists.

Of course, this doesn't solve your problem of cryptic error messages. I
can only say two things about that: (1) bugs are generally going to
result in cryptic behavior; there's very little we can do about that
aside from fix most of the bugs; and (2) the correct response to a
cryptic error message is not to plaster over it with documentation, but
to make it less cryptic. For instance, when you try to "svn export"
over an existing directory right now, you get:

  % svn export file:///var/ghudson/svn-test svn-test-exp

  svn_error: #21035 : <Can't find an entry>
    timestamps_equal_p: `grows' not under revision control

That's cryptic. We could make "svn explain 21035" mention that
exporting over an existing directory can cause this error, but it would
be much better to add a check for an existing target directory and yield
a sensical error message.

I also think we want to curb the expansion of our command set.
Bitkeeper is legitimately criticized as having way too many functions; I
don't think we want to go that route. But this is my smallest
objection, since it would be easily addressed by making a sub-feature of
"svn help" instead of making a new "svn explain."

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 3 19:53:47 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.