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_at_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_at_1 ext
>>
>>
>> $ svn proplist -r1 -R -v ^/
>> ...
>> Properties on 'file://localhost/D:/temp/externals/repo/src/dir':
>> svn:externals
>> ^/ext_at_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.
Received on 2015-04-23 15:54:46 CEST