Jonathan Gilbert wrote:
>
>> Now take this example:
>> c:\svn\wc\> svn diff G:test.txt
>>
>> If 'G:test.txt' would be considered a relative path, then Subversion
>> would think 'c:\svn\wc\G:test.txt' is the absolute path for test.txt,
>> which clearly is incorrect. So for practical reasons we consider
>> 'G:test.txt' as an absolute path, but you're right in saying
>> conceptually it's actually relative.
>>
>
> The C standard doesn't acknowledge this, obviously; getcwd() can only return a
> single value. Even within the Win32 API, GetCurrentDirectory() behaves like
> getcwd(), but there is an alternate function GetFullPathName() which can be
> used to find the current directory on other drives (one passes it a drive
> letter and a colon; the current directory on that drive is then assumed).
> The fact is, though, that Subversion (or the platform layer it is upon) do
> not consider the possibility of multiple filesystem roots, and thus the API
> functions involved don't have any way of taking these into consideration.
>
Interesting. As far as I'm concerned we do not need to know the cwd of
other drives. If the user refers to the cwd on drive G as 'G:', then the
output of svn should contain 'G:test.txt', not G:\svn\wc1\test.txt.
> To complicate things, Windows considers a UNC path specifying a share name
> to be a valid "drive letter" (though applications do not remember current
> directories relative to these beyond where the current directory *is* on a
> UNC path). That is, you can call
> SetCurrentDirectory("\\\\SERVER\\Share\\Path\\To\\Directory\\"), and
> "\\\\SERVER\\SHARE" is considered to be the "drive-letter" part. A
> subsequent call to SetCurrentDirectory("\\Another\\Directory\\") (note the
> lack of a drive letter) will be processed as relative to
> "\\\\SERVER\\SHARE". I don't know if this requires any special handling
> within Subversion, or if it "just works" because the values that filter
> down to the API happen to do the right thing. I'm fairly certain Windows is
> also the only OS with this complication as well, though :-)
>
Subversion never sets the current directory, but it should support unc
paths, represented internally as //server/share. In fact, up until
r23907, svn's path functions recognized Windows folders, UNC paths etc.
I added that feature and tests on trunk to get issues 1711 and 2556 fixed.
Problem is (and this is what this thread is all about) that the path
functions are used for directories - which should have Windows specific
behavior - and uri's without distinction between the two. So if someone
puts a file called 'c:hi' in the root of a repository using a linux
client, and then dumps or verifies the repository on Windows, svn
pre-r23907 will fail.
My changes handled things a bit differently than yours, if you like you
can check out r23907 to see how it used to work. This code will come
back later, as functions handling directories or uri's, but not both at
the same time.
Lieven
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Mar 25 18:21:02 2007