Hi,
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
out.
Thanks
Dan
Here's an example that fails for us:
c:\Project_files\sandbox_v2_renametest>svn pl -v 1122.txt
Properties on '1122.txt':
pebls:plcm
ETI_DEMO@4630
pebls:sha1
ba8cc41efc875a6dc8212ef76c579c1336597fe5
svn:needs-lock
*
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':
svn:needs-lock
*
c:\Project_files\sandbox_v2_renametest>
