[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Bug: properties on replaced files lost from working copies

From: Rob Hubbard <hubbard.r_at_gmail.com>
Date: 2007-11-06 11:53:08 CET

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

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:

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
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

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?


Rob Hubbard

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

Received on Thu Nov 8 00:43:33 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.