Re: Ev2 file/dir modifications and properties

Branko Čibej wrote:

> It just eneterd my consciousness that Ev2's alter_directory and
> alter_file operations apparently expect to receive a full set of
> properties, if even one prop is being altered or deleted. I haven't
> tested if that is in fact how it works, but it seems to me to be the
> same kind of design bug as the list of children on a directory; i.e., it
> would be a lot better if we sent a property diff instead of the whole set.
>
> Thoughts?

As I understand it, the Ev2 API design is premised on the idea that the sender knows the full initial state against which it is describing a change, and so it isn't a problem to provide a complete list at the API level. At the implementation level, the sender may choose to encode the transmission as a delta against the initial state, if both itself and the receiver know the initial state.

During "update" and "commit", the operations Ev2 was targetted at, both the server and the WC are supposed to know the initial state. The server clearly knows everything, but does the WC know enough? Even with excluded nodes etc.? Does the WC know enough about what children of a directory "belong" to it in the repository, even in a mixed-revision state? I'm not sure.

If we try to use Ev2 for a non-WC commit, such as "svn mkdir ^/A/B" or "svn propset p v ^/foo" [1], then we run into the problem that the client doesn't know the initial state. There, the Ev2 API is not appropriate. We could change Ev2 to be more suitable for these cases, or it may be better to use some other API for these cases.

- Julian

[1] The command-line client currently does not support prop-set on a URL, but in priniciple it could.

  sender (client) says to API: "
Received on 2013-10-30 10:44:11 CET