You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by cm...@collab.net on 2003/05/08 02:17:55 UTC
Re: [Issue 1291] Changed - Incorrect path in "not a working copy" error message.
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
Re: [Issue 1291] Changed - Incorrect path in "not a working copy" error message.
Posted by cm...@collab.net.
=?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <br...@xbc.nu> writes:
> >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
> >
> Why not? This is what Windows users expect.
Alrighty. Fair enough. Probably not terribly common case anyway,
since Windows users wouldn't expect to be able to use forward-slashes
for input.
> Yikes. Watch this:
>
> C:\> svn st -v wc/subdir\subsubdir/subsubsubdir\file13.5
>
> How many bits do you want to store? :-)
Point taken. :-) Okay, considering this and your bulleted list of
Wrapper Script Solutions That Mike Shouldn't Worry About, I'm toggling
my opinion on this matter to a nice, concise, +1.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: [Issue 1291] Changed - Incorrect path in "not a working copy" error message.
Posted by Jack Repenning <jr...@collab.net>.
> But it complicates those scripts by forcing them to convert
> to local before using paths. Secondly, users could no longer
> cut-n-paste from the output of "svn st" into a shell or
> file-selection dialog.
Paths with "/" work at shell, file-selection, and Windows Explorer
interfaces on my Windows box. I'm currently using XP, but I've been
doing that sort of thing since at least NT 4.0. All the scripting
languages I ever use are happy with "/" too (that would be: perl,
python, Java, sh, and bat).
The only place "/"s cause problems (that I know of) are when handed to
individual programs that use "/" for options. For example, the DOS
"find" command thinks any "/" is about options, and expects paths to use
"\". Visual Basic might be a problem too, I wouldn't know (but I'll bet
a cookie it's OK;-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 1291] Changed - Incorrect path in "not a working copy" error message.
Posted by mark benedetto king <mb...@boredom.org>.
On Wed, May 07, 2003 at 11:42:24PM -0500, kfogel@collab.net wrote:
>
> I mean, sure, if you carefully write the script to accept both kinds
> of separator. I think Mike means something like: if our output always
> uses "/", then anyone who writes an output-parsing script can depend
> on "/" as the separator.
>
But it complicates those scripts by forcing them to convert to local
before using paths. Secondly, users could no longer cut-n-paste from
the output of "svn st" into a shell or file-selection dialog.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 1291] Changed - Incorrect path in "not a working copy" error message.
Posted by kf...@collab.net.
Branko Čibej <br...@xbc.nu> writes:
> >But to be reeeeeeally honest, I'd rather have the output be
> >OS-independent so that wrapper scripts are instantaneously (more)
> >portable.
> >
> Really? Which wrapper scripts?
>
> * Shell scripts: inherently non-portable, not worth the bother.
> * Python, Perl: Can handle both forward and backward slashes on Windows.
> * Emacs: ditto.
> * vi: don't know and don't give a damn.
Huh?
I mean, sure, if you carefully write the script to accept both kinds
of separator. I think Mike means something like: if our output always
uses "/", then anyone who writes an output-parsing script can depend
on "/" as the separator.
I'm not arguing for or against Mike's point, merely trying to make
sure it gets understood. It's meaningless to say that Python and Perl
"Can handle both forward and backward slashes on Windows". They can
handle them if you wrote the script that way, but any such script will
be a bit more complex than a script which just handles one or the
other.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 1291] Changed - Incorrect path in "not a working copy"
error message.
Posted by Branko Čibej <br...@xbc.nu>.
cmpilato@collab.net wrote:
>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
>
Why not? This is what Windows users expect.
>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.
>
Yikes. Watch this:
C:\> svn st -v wc/subdir\subsubdir/subsubsubdir\file13.5
How many bits do you want to store? :-)
>But to be reeeeeeally honest, I'd rather have the output be
>OS-independent so that wrapper scripts are instantaneously (more)
>portable.
>
Really? Which wrapper scripts?
* Shell scripts: inherently non-portable, not worth the bother.
* Python, Perl: Can handle both forward and backward slashes on Windows.
* Emacs: ditto.
* vi: don't know and don't give a damn.
* Windows batch: non-portable, but can't handle forward slashes, so
it's actually better to have the output in the correct format
You have no ides how happy I am that VMS is practically dead. Now _that_
file name syntax was a perfect mess. :-)
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org