On Thu, 10 Nov 2005, Daniel Berlin wrote:
>
> >
> > The problem with using a string for this is space. An apr_uint32_t
> > with bits for signle props would be more space-efficient than a little
> > string for each entry. NOt that we are terribly space-efficient for
> > the entry cache, but that's another topic.
>
> This is true, and if you want, i'll move it to a uint32.
> But i think we should still write it out as a string.
>
This was discussed on IRC and I concluded that I can live with a
space-separated string (also see Dan's follow-up). Anyone else dislikes
this?
> > Why do we need this as a public API. I'd like to keep this as an
> > implementation detail.
>
> Okay, that's fine.
There might actually be a reason for a user application to know if a
certain property is cached. I'm thinking of svn:needs-lock. GUI might
think this is too expensive to retrieve for each file in a directory
listing if it is not cached and use the filesystems read-only state
instead. In that case this is dependent of the actual working copy. I
don't know if this is needed in practice. Let's wait until the need
arises. It is trivial to implement in that case.
> > >
> > > That TODO is for the above:-) But, sadly svn_wc__install_props is not
> > > the only place where we muck with the properties.
>
> If you stare about, you will discover this really is the only place that
> seems to need to be changed.
> The other places you might think need to changed (like prop_set2) call
> install_props.
>
Discussed on IRC as well. I think revert_admin_things was the only other
place.
> > > +
> > > +const char *
> > > +svn_wc_cached_properties (void)
> > > +{
> > > + return SVN_PROP_SPECIAL "," SVN_PROP_EXTERNALS "," SVN_PROP_NEEDS_LOCK;
> >
> > This list can be tweaked during the 1.4 cycle.
>
> Every time you add to the list, you will break existing wc's with newer
> clients. Every time you delete from the list, you will break newer wc's
> with older clients. :)
>
Yes. That's why we'll need another wc format bump during the 1.4 cycle.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 11 08:45:24 2005