Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com] 
>> Sent: Wednesday, September 12, 2007 6:01 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: svn commit: r574618 - in 
>> /incubator/stdcxx/trunk: README configure.bat generate.bat
>>
>>>   AFAIK the svn-client not support symbolic links on windows.
>> I thought the file would end up getting copied on Windows. 
>> That's what Perforce does (which is probably why I thought 
>> that). If it doesn't, why don't we create a wrapper 
>> generate.bat script and invoke configure.bat from it as the 
>> temporary solution.
> 
>   I will create it.

Great, thanks.

> 
>>>   Because of that the filebuf example always fail with DIFF 
>> status on 
>>> my workstation (the manual/out/filebuf.out is a symbolic link to 
>>> manual/filebuf.cpp, but on windows the content of this file is just 
>>> single line: "link ../filebuf.cpp").
>>>
>>>   I surprized how this example runs with status 0 in nightly builds.
>> You think there's a problem there?
> 
>   I think there no problem when user downloads the stdcxx library in
> archive. 
> 
> When I downloaded the 4.1.3 release
> (http://cvs.apache.org/dist/incubator/stdcxx/releases/stdcxx-incubating-
> 4.1.3.tar.gz)
> and extracted it, the filebuf.out is correctly copied from filebuf.cpp
> by
> archiver (I have used WinRAR).

Right, that's probably because tar on Windows must be smart enough
replace symlinks with the files they point to, if they point within
the tarball.

So the problem only occurs when someone checks out the repository
on Windows. Subversion should know to do the same thing as Perforce
on Windows instead of expanding the contents of the link. This seems
like an svn bug or at least a bad limitation. I'm not sure there's
anything we can do about it short of avoiding symlinks.

Martin