[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?

-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

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.