Philip Martin wrote: > Julian Foad <julianf...@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" > message. > >> 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 Quite. > 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. - Julian