On Saturday 03 August 2002 3:22 pm, Martin Pool wrote:
[I said:]
> > I propose that typing, e.g., "svn explain 21087" should yield
> > a friendly description, one or two paragraphs long, of
> > what that error means, what's likely to have provoked it,
> > and what to do about it. Perhaps this should be generalized
> > beyond error messages: "svn explain transaction" could
> > give a brief explanation of what a transaction is.
>
> Some people have previously expressed concern about the idea of
> putting too much documentation into the binary.
>
> Here's a counter-proposition: have a web site giving the same
> information, and easily searchable by error ID. Allow space for
> people to post followups giving additional information.
>
> One advantage is that people with old versions of svn can still get
> more up-to-date help, and it's easier for updated info to be
> accepted onto a site than merged into the main source.
I see two disadvantages to that, compared with putting the
information in the binary. (The *advantages*, I take it, are
obvious.)
1. I see nothing that guarantees that the error IDs will never
change. They're allocated sequentially-by-magic in
svn_error_codes.h, and if someone ever adds a new one
then all the later errors will get their IDs bumped up. Since
they are (currently) arranged in groups, it seems quite
likely that errors will get added in the middle of the list.
So the searching would have to be by error *message*,
which is a bit more cumbersome.
2. It's possible that the most appropriate message will
need to change from one version to the next. For instance:
I recently found what I think is a bug that leads to an
incorrect "Transaction out of date" error. If I'm right to
think it's a bug, and if it turns out to be easy to work
around and hard to fix, then for a few versions it might
be beneficial to add something to the corresponding
error description along the lines of "There's a known
problem with the version of Subversion you're using
that sometimes causes this error. Try doing X instead,
or see if the problem has been fixed in the latest version.".
Looking back at a thread from mid-July (don't know how
I missed it before), I see Ben suggesting a "svn help"
feature along similar-ish lines, Karl -0 on it, Brian Fitzpatrick
-1, and a certain Martin Pool actively in support. :-)
--
g
---------------------------------------------------------------------
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:00:46 2002