I ran into this problem as well. It was reported as bug #2064:
http://subversion.tigris.org/issues/show_bug.cgi?id=2064
If you don't want to use the latest version from the trunk, then to work
around it, you could wrap your svn merge operations in scripts that
check after the merge is complete if files that were merged have the
svn:special property set on them and are not symlinks. At that point,
you can read the files to figure out what the correct target is, and
then replace the text file with the actual symlink.
Brian
Mario Amaro wrote:
>I am working on redhat linux 9.0 and subversion 1.1.3 and I have the
>following problem:
>I have two consecutive revisions: 1 and 2.
>The only difference between them is that revision 2 has one extra valid
>symbolic link named 'mysymlink' that links to a file named 'myfile'
>If I checkout revision 1 and the update to revision 2 the symbolic link pops
>up OK.
>The problem is this: I have revision 10. This revision does not have the
>extra symbolic link.
>I want to insert it in revision 10 so I type
>
>svn merge -r1:2 file:///path/to/repos .
>
>and the command returns OK, but then I find out that the file 'mysymlink'
>exists but it is not a symbolic link. Instead, it is a plain file whose
>contents are 'link anotherfile'
>I mean:
>
>
>>cat myfile
>>
>>
>link anotherfile
>
>
>
>Is this a bug or is it intended behaviour?
>
>Regards,
>
>Mario
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 19 20:18:56 2005