I think this sound like a good idea. I'm changing my vote on this one.
Specifically, I think that any non-user properties (svn_*) should be
hidden by default when the user gives a command-line "proplist"
command. "proplist" should require special flags just to *see*, not
only change, these system properties.
Karl Fogel <kfogel@galois.collab.net> writes:
> Actually, I think we decided (and with good reason) that even
> Subversion-specific properties would be stored alongside regular
> properties, just under their own namespace prefix, or using some other
> perfectly reliable ownership mechanism. So Greg, your ra properties
> would have names like "svn_ra_*", or something similar.
>
> It's true that if someone corrupts these properties, then the working
> copy could become broken as far as repository communications goes.
> But this is always true of any working copy adm data: if you change
> things without understanding what you're changing, then you should
> expect things to go wrong.
>
> The danger is not very great, because SVN clients can easily protect
> users from modifying Subversion's private properties, either by
> entirely disallowing setting them, or by requiring a --force flag to
> set them. Any client can recognize an SVN property by inspecting the
> property's name (and we'll provide a library function for that too, of
> course).
>
> So I think the best thing would just be to use the regular property
> interface. (I can't remember if this is complete yet, but you get the
> idea: if it's not ready and you need it now, then we'll make it
> ready).
>
> How does that plan sound?
>
> -Karl
>
> Ben Collins-Sussman <sussman@newton.collab.net> writes:
> > Greg Stein <gstein@lyra.org> writes:
> >
> > > I'd like to propose that a hashdump file is created where RA libraries can
> > > store properties. There are a couple properties that I'd like to store.
> > >
> >
> > Other than defining these new objects within SVN/, there's nothing
> > Karl and I need to here, right? I mean, you'll be reponsible for
> > managing these "ra" props?
> >
> > If so, sounds like a good idea to me.
> >
> > I assume there's no need for "working" versus "pristine" ra-props.
> > Still, though, Karl's function for accessing administrative areas
> > assumes that SVN/tmp/ra-dir-props and SVN/tmp/ra-props/ still exist:
> >
> > /* Return a path to something in PATH's administrative area.
> > * Return path to the thing in the tmp area if TMP is non-zero.
> > * Varargs are (const char *)'s, the final one must be NULL.
> > */
> > svn_string_t * svn_wc__adm_path (svn_string_t *path,
> > svn_boolean_t tmp,
> > apr_pool_t *pool,
> > ...);
> >
> > I'm kinda curious -- what sort of props does RA need to track? :)
Received on Sat Oct 21 14:36:16 2006