[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: more property thoughts

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-02-08 00:22:25 CET

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?


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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.