On Wed, Jun 27, 2018 at 1:07 PM, Dipu H <di...@juniper.net> wrote: > Hi Team, > > I have a patch with svn property changes as below: > > dipuh@contrail-ubm-MADHUS:/tmp/tests$ svn diff xpathleak.py > Index: xpathleak.py > =================================================================== > --- xpathleak.py (revision 950359) > +++ xpathleak.py (working copy) > @@ -4,25 +4,15 @@ > libxml2.debugMemory(True) > > expect="""--> Invalid expression > ---> xmlXPathEval: evaluation failed > --> Invalid expression > ---> xmlXPathEval: evaluation failed > """ > err="" > def callback(ctx, str): > > Property changes on: xpathleak.py > ___________________________________________________________________ > Modified: svn:executable > ## -0,0 +1 ## > +* <<<<<<<------------- Yes, there is a change, value * added to property > svn:executable > \ No newline at end of property > Added: svn:mime-type > ## -0,0 +1 ## > +text/plain > \ No newline at end of property > > ================================ > > Now I generated the patch and applied it on another copy of the same branch. > > dipuh@contrail-ubm-MADHUS:/tmp/tests$ svn diff xpathleak.py >/tmp/mypatch > > dipuh@contrail-ubm-MADHUS:/tmp/apply$ svn patch /tmp/mypatch > UC xpathleak.py >> rejected hunk ## -0,0 +1,1 ## (svn:executable) > Summary of conflicts: > Property conflicts: 1 > > The patch is rejected without changing the property. The destination file > already has svn:executable property present in it. But the value is empty. > Ideally, if the patch was applied properly, the value should have been > changed to "*". > > > After little bit of googling, I found the below link which looks like a > similar issue. > > https://jira.atlassian.com/browse/CRUC-6114?src=confmacro > > SVN Version : 1.8.11 > > > > I understand that the latest svn clients add * as the value of > svn:executable property. However, if we generate a patch out of this and > apply on an existing file, `svn patch` is not able to identify that there is > a property change from ‘null’ to ‘*’. Could you please check if this is a > bug?
SVN 1.8.11 is very old (version 1.8.x is actually end-of-life now [1]). Can you test with a 1.10 client to see if it shows the same behaviour? [1] http://subversion.apache.org/docs/release-notes/1.10.html#svn-1.8-deprecation -- Johan
