Ben Collins-Sussman <sussman@collab.net> writes:
> That's all fine and well, but if we move to this new paradigm of 'a
> proplist means *all* props', then we need to go -both- directions.
> IOW, when we receive a proplist from the server, somebody eventually
> ends up parsing the property namespaces and storing them in 3
> different locations. But just as often, the merging process (and
> other processes) require reading existing proplists from disk (for
> comparisons, etc.) So we'll need a single 'read_proplist' routine
> that will *suck* the data from 3 locations and combine them into one
> hash.
>
> Am I making sense?
[I think I may just be echoing Greg's reply to this.]
When going from client to server, I think we only need to send regular
svn properties -- not wcprops, and not entry props.
In the case of wcprops, anyone who needs to send them to the server
would fetch them and do so (e.g., ra_dav).
In the case of entry props, at various points in various operations,
we fetch them *from the entry* (using a mechanism unrelated to the
propget code) and use them in whatever manner is appropriate.
I don't see how either of these will be changing, so I think we're
just going to handle properties coming from server->client different
than those going from client->server. There will just be more types
of props in the former case than the latter, and the receiving code in
the client will filter as necessary.
Does this make sense?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:05 2006