Ev2 file/dir modifications and properties

[Branko Čibej <br...@wandisco.com>]

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?

-- Brane


-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com

Re: Ev2 file/dir modifications and properties

[Greg Stein <gs...@gmail.com>]

On Wed, Oct 30, 2013 at 4:43 AM, Julian Foad <ju...@btopenworld.com> wrote:
> 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.

Exactly. A set of properties is very easy conceptually and at the
implementation. A delta is more difficult, and not really necessary.

The full set of properties and the list of children are also part of
the desire to be atomic. The call says "set the state to <this>" and
you're done. The (new) children may be set to incomplete (aka
known-but-undefined), but the directory doesn't need any special
status.

Cheers,
-g

Re: Ev2 file/dir modifications and properties

[Julian Foad <ju...@btopenworld.com>]

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: "