Farid Zaripov wrote:
-----Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED]
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
