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

Re: [Issue 1291] Changed - Incorrect path in "not a working copy" error message.

From: <cmpilato_at_collab.net>
Date: 2003-05-08 04:17:55 CEST

issues@subversion.tigris.org writes:

> http://subversion.tigris.org/issues/show_bug.cgi?id=1291
>
> *** Old
> --- New
> ***************
> *** 45,47 ****
> --- 45,55 ----
> the abspath would be nice.
>
> The /home/ralph line is definitely wonky...
> +
> + ------- Additional Comments From brane@tigris.org 2003-05-07 18:40 PDT -------
> + "." is correct. We convert the canonical "" to the user-friendly "."
> + on output in a number of places, but not everywhere, it seems.
> +
> + Actually, we should call svn_path_local_style whenever we output a
> + path (not an URL!), and that function should take care of the "" ->
> + "." conversion.
> \ No newline at end of file

I've not bothered to read the implementation promises of this
function, but I'm concerned that calling svn_path_local_style on all
output paths will make output be inconsistent in format from input.
Because it's perfectly okay on Windows to use forward slashes for
paths, I don't want this to happen:

   C:\> svn st -v wc/subdir
   _M 10 10 cmpilato wc\subdir
   M 10 10 cmpilato wc\subdir\file1
   A 10 10 cmpilato wc\subdir\subsubdir

Note the output path style that differs from the input. Perhaps we
could store a bit in the context baton at the time we call
svn_path_internal_style() saying that internal style was already in
use or something. I dunno.

But to be reeeeeeally honest, I'd rather have the output be
OS-independent so that wrapper scripts are instantaneously (more)
portable.

Just a thought or two.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 8 04:22:06 2003

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.