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
