On 20.07.2018 12:46, Julian Foad wrote:
> Julian Foad wrote:
>> Daniel Shahaf wrote:
>>> Dmitry Pavlenko wrote on Thu, Jul 19, 2018 at 19:03:30 +0200:
>>>> I'm not 100% sure that [...] is the expected output [...]
> [...]
>>> I suggest that we add a regression test that simply expects any output [...]
> But on Windows the buildbots have discovered that this 'diff' command does not error out, and so this test gives an XPASS result (which we choose to treat as an overall failure of the test suite).
>
> What to do? Add in some reasonable expectation?
>
> We need to design the expectation.
>
> Intuitively I expect a replacement of file with symlink to be presented as file deleted and symlink added, not as a content-modification (from normal file content to the 'special' representation of the symlink).
>
> Does that make sense, anyone? Does that fit with our architecture whereby knowledge of 'special files' is client-side?
>
> Presumably we would want a diff requested by the client to behave the same way, regardless whether the two items being diffed are located on the server and/or on the client. In contrast, if we request a diff through a server-layer tool such as 'svnadmin' then presumably it must display a content-modification and property-modification, because it is looking at the server-side representation of a symlink (using a 'special file').
>
> How does this fit with our ideas of object lifelines? Was that a replacement, starting a new lifeline, or not?
That's a tricky question. You can always add an svn:special property to
a file and modify its contents to the correct format. It's still the
same object; the server won't care.
It becomes a new object lifeline if the equivalent of the following
happened on the client:
svn rm foo
ln -s /some/thing foo
svn add foo
Then it's just a replacement of file by file as far a the server is
concerned.
(Could be we have checks in the client that forbids manually adding
svn:special, but I can't recall).
-- Brane
Received on 2018-07-21 13:02:43 CEST