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? In any case, this is a cosmetic issue in practice. But I agree it should be fixed. > $ 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.
