Greg Stein <gstein@lyra.org> writes:
> That sounds like a fine approach to me.
> 
> And note that I'm using URIs to name properties, not something simple like
> svn_ra_* :-)
Cool, that's even better.  Make sure the default prefix is longer than
80 characters, so it never fits on a standard terminal.
(Ducks,)
-K
> On Mon, Dec 04, 2000 at 08:40:29AM -0600, Karl Fogel wrote:
> > 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?  :)
> 
> -- 
> Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:16 2006