On 23.04.2015 11:27, Stefan Sperling wrote: > On Wed, Apr 22, 2015 at 07:58:35PM +0200, Marc Strapetz wrote: >> After invoking following series of commands: >> >> svnadmin create repo >> svn checkout file://localhost/d:/temp/externals/repo wc >> >> mkdir wc >> cd wc >> mkdir ext >> touch ext\file >> >> mkdir src\dir >> svn add * >> svn propset svn:externals "^/ext ext" src >> svn propset svn:externals "^/ext@1 ext" src\dir >> svn commit -m "initial import" >> >> svn up >> svn cp --pin-externals src ^^/dst -m "copy" >> svn log -r2 -v >> svn proplist -r2 -R -v ^^/ >> svn proplist -r1 -R -v ^^/ >> >> The final log output shows /dst/dir as modified: >> >> ------------------------- >> r2 | marc | 2015-04-22... >> Changed paths: >> A /dst (from /src:1) >> M /dst/dir >> >> copy >> ------------------------- >> >> However, there is no modification expected, because src\dir external already >> has a revision number set. The proplist outputs confirm that the property >> hasn't been modified: > Interesting. I suspect this comes about because the pin-externals code > always sends a propchange in the commit transaction. Apparently the > repository will happily record a no-op change. It seems the client > should avoid sending a propchange with an empty delta? > > Or should the server be fixed to collapse empty propchanges to nothing? > What does it do for no-op file content changes sent by clients?
We've always supported no-op changes in the repository. As far as this is even an issue, it's a client-side thing. > In any case, this is a cosmetic issue in practice. But I agree it should > be fixed. Yes, the pinning code should avoid no-op propchanges. -- Brane > >> $ svn proplist -r2 -R -v ^/ >> ... >> Properties on 'file://localhost/D:/temp/externals/repo/dst/dir': >> svn:externals >> ^/ext@1 ext >> >> >> $ svn proplist -r1 -R -v ^/ >> ... >> Properties on 'file://localhost/D:/temp/externals/repo/src/dir': >> svn:externals >> ^/ext@1 ext > To rule out whitespace differences, can you please send these outputs > through hexdump or diff to ensure they really are identical? > I believe they are, just checking.
