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

SVN Rename doesn't always copy custom properties

From: Dan Ellis <danellis10_at_gmail.com>
Date: Thu, 30 Apr 2015 11:48:22 -0700


I posted this first to the users@ group, but no one has been able to
reproduce the behavior. We are running various minor revisions of SVN
1.8.9 and above on Windows 7 on an Apache server.

We use custom properties for tracking data on a file by file basis. When
we perform an SVN rename, the custom properties do not always make the trip
over. If there are svn-specific properties like needs-lock, they do
transfer. This is not completely consistent - sometimes the properties DO
copy over fine.

We are trying to determine the magic scenario that sets the stage for this,
but have not had success yet. We have tried cleaning up the working
copies, new checkouts of working copies, and various changes to properties
such as removing the '@' but it still occurs.

We have seen this behavior on multiple repos on the same server, though
unless the properties are somehow messed up on, it would seem to be a
client issue (the delete/add action is where the properties are lost).

As a possible lead, we do have some automation where we specifically copy
properties (only) through a diff and patch process between files (diff
--old foo.c --new bar.c --properties-only > tempfile; patch tempfile).

While we continue to try and narrow down the scenario to make it
reproducible, I thought I'd check to see if anyone had any insight into
what could trigger this behavior or give us some possible pointers to check


Here's an example that fails for us:

c:\Project_files\sandbox_v2_renametest>svn pl -v 1122.txt
Properties on '1122.txt':

c:\Project_files\sandbox_v2_renametest>svn rename 1122.txt 111222.txt
A 111222.txt
D 1122.txt

c:\Project_files\sandbox_v2_renametest>svn pl -v 111222.txt
Properties on '111222.txt':

Received on 2015-05-04 07:04:49 CEST

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