Philip Martin wrote:
> Julian Foad <julianfoad_at_btopenworld.com> writes:
>>> The diff reports have
>>> no equivalent of log's text-mods/props-mods but they do communicate that
>>> a new node was created. The diff client could choose to output some
>>> sort of "new node" message.
>> (I assume you mean "new node-revision".)
> More that the client could report some sort of "new version of file"
>> You have observed this
>> correlation between new node-revs and editor method calls in the
>> current typical Subversion software configuration. The client should
>> not assume that an "open-dir" or "open-file" editor method call means
>> a new node-revision in the file system. Node-revisions are meant to be
>> a private implementation detail of the repos or FS layers.
> The RA layer is public API. At present the RA layer invokes open_file
> in the client's delta editor when there is a no-op text change so this
> is a visible to the client.
In a typical Subversion software package built from client and server software libraries supplied by us, yes, that behaviour happens, among other things that happen.
> Our client chooses not to report this to
> the user but other clients might choose differently. It's not entirely
> clear what the client can assume about an open_file that is not followed
> by either apply_textdelta or change_file_prop
> but it would not be
> unreasonable for a client to report that it received open_file.
And my point is it *would* be unreasonable because (a) users have no use for being told merely that a certain method was invoked in the software interface; and (b) we have assigned no meaning to this event other than, in my opinion, by happen-stance. In particular, other implementations of any software layer involved in the procedure may produce different behaviour.
I want to say that it is very important that we distinguish between deliberate, meaningful, useful behaviour and happen-stance behaviour that nobody wants but that happens to occur in some conditions.
Received on 2014-09-22 20:14:08 CEST