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

Re: svn commit: r11838 - trunk/subversion/libsvn_subr

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2004-11-12 19:50:00 CET

Greg Hudson wrote:
> On Fri, 2004-11-12 at 09:24, kfogel@collab.net wrote:
>
>>>BTW, when did we decide to always return absolute paths in error messages?
>>
>>Frankly, I'm not sure, although I can think of arguments for and
>>against. I think I lean slightly toward "for". But mainly I was
>>assuming (perhaps wrongly) that issue #1538 indicated some sort of
>>pre-existing consensus about this.
>
> Well, I'm pretty strongly against. It looks clunky to type "svn update
> foo" and see an absolute path to 'foo' in the error message.

Oh dear. I've just seen in the log that this was a preliminary patch of mine
from over a year ago. I remember now that the objection to reporting an
absolute path was raised. Philip Martin replied with some good reasons against
doing so. Also the "###" comments don't belong in it (suggestions about future
evolution of the software generally belong on the mailing list or issue tracker
or whatever rather than in the code). Also the final "apr_psprintf" is
redundant (it was there because I had been going to use it to add single quote
marks around the file name, and remove them from all the individual messages,
but then I decided not to).

I'll fix up that function soon (and not have it convert paths to absolute) if
Karl doesn't get to it before me.

I should go through any other outstanding patches that I might have filed, and
see if they are still OK. Not promising I will, though. Just take old patches
with caution.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 12 19:50:33 2004

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.