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

Re: [RFC] Paths API (svn_dirent_uri.h) - improvements

From: Branko Cibej <brane_at_xbc.nu>
Date: Wed, 11 Nov 2009 14:29:33 +0100

Stefan Sperling wrote:
> On Wed, Nov 11, 2009 at 12:25:49PM +0000, Julian Foad wrote:
>
>> DIRENT:
>>
>> A "dirent" represents a native operating-system path... but let's be
>> clear exactly what kinds of absolute and relative path this includes.
>>
>> The representation seems a bit odd, using Subversion's "canonical path"
>> rules ("/" separator, etc.), rather than the native form, and so
>> requiring "to_internal_style" and "to_native_style" conversions.
>>
>
> One observation I've made recently: On UNIX, passing a path containing
> backslash-separators (e.g. a path parsed from a patch file) to
> svn_dirent_internal_style() does absolutely nothing.
> It just returns the path unmodified.
>
> On Windows, passing a path containing backslash-separators
> to svn_dirent_internal_style() does convert any backslashes
> to forward slashes...
>
> So the to_internal_style and to_native_style don't even work
> as one might expect -- they don't always convert to the internal
> style, it depends on the platform.
>

They work *exactly* as expected. Those functions are meant to convert
valid user input to the format Subversion use internally; by
implication, they have to behave in a system-dependent way.

On Windows it's very likely that your editors or IDEs or compilers will
understand backslash-separated paths. That's "somewhat less" likely on
Unix. In other words, if you tell Subversion on Unix to commit
this\mess, it'll fail with a similar error as if you try to "vi this\mess".

-- Brane

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2416558
Received on 2009-11-11 14:30:00 CET

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.