RE: svnsync: properties not always copied?

> -----Original Message-----
> From: Dustin Lang [mailto:dstndstn_at_gmail.com] On Behalf Of Dustin Lang
> Sent: maandag 18 november 2013 18:10
> To: users_at_subversion.apache.org
> Subject: svnsync: properties not always copied?
>
>
> [I am not on the list; please cc me in replies]
>
> Hi,
>
> I keep an svnsync'd mirror of my svn repository, and I run a very
> stringent verification check: I do an "svnadmin dump" on the original and
> the mirror, and demand that they have the same md5sum. It is paranoid,
> but paranoia is good when it comes to backups!
>
> Problem is, in some situation that I haven't nailed down, some properties
> don't seem to get set in the svnsync'd version. I think it happens when I
> make a tag, ie, copy a directory, that has properties set. For example,
> in the "svnadmin dump":

        Hi Dustin,

Your description of your problem sounds like something that might be very
important to fix, but it doesn't describe a way for us to reproduce the
problem. This makes it very hard for us to spend time on this issue.

Your example 'svn:mergeinfo' missing could be caused by older Subversion
clients that in some specific merge cases committed unmodified properties as
modified. When the replay code then calculates which property changes should
be reported, the no-change properties are not reported.
(All known cases of this problem should be fixed in Subversion 1.8.X
clients)

So there might be changes that are no real changes in the lower fs layers of
subversion that would be noted as 'no change' by the upper layers, which
could explain exactly what you are seeing: a difference between dumping via
the lower and higher layers.

Is there some way you can show us how you find the problem or how we can
reproduce the problem. That way we can try to find the root cause, and see
if there is something we can fix.

--
If you want to try reproducing the case I described here you need a
Subversion 1.7 or older client and merge directories that contain
properties. Subversion 1.7 will then just commit the properties that were
copied, as if they were locally changed into what they were before they were
copied.
As normal user you would probably never notice this problem... But we found
out about it when fixing some tree conflict cases in merging during 1.8
development.
--
Thanks,
	Bert
> 
> --------------------------------------------------------
> Node-path: tags/nova/2013-11-04-1
> Node-kind: dir
> Node-action: add
> Node-copyfrom-rev: 24017
> Node-copyfrom-path: trunk/src/astrometry
> Prop-content-length: 92
> Content-length: 92
> 
> K 10
> svn:ignore
> V 6
> *.pyc
> 
> K 13
> svn:mergeinfo
> V 30
> /tags/nova/2012-06-27-2:21009*
> PROPS-END
> --------------------------------------------------------
> 
> in the svnsync'd mirror:
> 
> --------------------------------------------------------
> Node-path: tags/nova/2013-11-04-1
> Node-kind: dir
> Node-action: add
> Node-copyfrom-rev: 24017
> Node-copyfrom-path: trunk/src/astrometry
> --------------------------------------------------------
> 
> This sounds a bit like closed issue 4184:
>    http://subversion.tigris.org/issues/show_bug.cgi?id=4184
> 
> I am using subversion-1.8.4.
> 
> For what it's worth, the mirror is on another machine and connects via
> svn+ssh.  This svn repo was created in 2005, and is format "3" (versions
> 1.5+).
> 
> Unfortunately, I was unable to create a simple test case demonstrating the
> problem, so maybe it is some more complicated circumstance than the
> properties and directory copy, or maybe it has to do with having an old
> repo?
> 
> Any hints on what could trigger this would be much appreciated!
> 
> Thanks,
> --dustin