Bug: properties on replaced files lost from working copies

Dear SVN Developers,

[Please CC replies to me, as I'm not subscribed to this list.]

(Firstly, thanks to you all for your continued work on SVN. It's a
great program. And I'm waiting anxiously for some of the planned new
features...)

I've found a bug that does not appear to already exist on the issue tracker.

I have updated my copy of SVN to the latest version, 1.4.5, and the
problem is still present.

The problem is as follows.
    Suppose that you have the following files with properties in the repository:
        trunk/file.txt
            svn:eol-style=native
        branches/branch/file.txt
            svn:eol-style=native

Now suppose that you replace the trunk file with one from the branch:
    $ # in a working copy of trunk...
    $ svn del file.txt
    $ svn cp svn://repos/branches/branch/file.txt -r HEAD .
    $ # explicitly set the property again, to be sure
    $ svn propset "svn:eol-style" "native" file.txt
    $ svn commit -m"replaced file with one from the branch"

Following these steps, the property is missing from that file in the
working copy:
    $ svn propget "svn:eol-style" file.txt
produces an empty reply.

An update makes no difference.

However, the repository appears to be correct:
    $ svn propget "svn:eol-style" svn://repos/trunk/file.txt
    native
and in fact, a fresh checkout is also fine.

I'm running Windows XP Professional x64 Edition version 2003 Service
Pack 2 with the pre-built Windows installer version of SVN
<svn-1.4.5-setup.exe>.

Sorry not to find a "buddy", but I am certain that this is a bug.
Sorry too if this *is* already a known bug that I've missed in the
issue tracker.

I hope attachments are okay. (I couldn't find a policy statement on
that.) I have attached a Bash script <repro.sh> [which could be run on
Cygwin, or Linux if the bug also exists there], and a log of the
generated output <out.txt>. The script creates a repository (locally)
and all the files necessary to demonstrate the problem, and uses the
file:// scheme. The problem can be seen at line 110 of <out.txt>. Both
attachments are text files with LF-only line endings. I have
deliberately not zipped them, but they are small.

Could you please copy me on any replies as I am not subscribed to this list?

Thanks,
Rob.

Rob Hubbard

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org