Re: Issue 1538 -- local path style

D.J. Heap wrote:
>
> The rest of this issue involves error messages. There are hundreds I
> have found so far that use internal style paths, and in several cases
> the path could be a url -- no distinction is made, so a url check would
> need to be made before calling the conversion function, before passing
> the path to the error creation function. Should I proceed with this?
> Any comments or recommendations?

Don't add special code to every place that generates such an error message. Use a single common function to convert a path to a form suitable for display. There are several potential things to do to a path in an error message:

* Make it absolute, so that the user can find it without having to know or guess what the current working directory was at the time. If it is going to be displayed as relative, at least display "." instead of "".

* Make sure it is quoted: not only enclosed in quotation marks, but also any funny characters within it should be quoted in some unambiguous way.

* Use the native path separator (backslashes on Windows, etc.), which is what you are interested in.

Attached is a patch that I started on recently which goes some way towards this. I am not very happy that my function "path_for_err_msg" needs to take a "pool" argument, because this makes the calling syntax even longer than it would be already, but I can't see an easy way to work without it.

Please feel free to use and extend this as you wish. I only got as far as applying it throughout the one file "io.c" which is why the function is "static", but it should obviously become global if it is to be useful.

This formatting function could, if people wish, be configurable: e.g. if absolute paths are unwieldy in most cases, it could print relative paths by default and only when someone is stuck not knowing where to look they could re-try the operation with a configuration option (debug level) set to display absolute paths.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 25 01:40:22 2003