Greg Stein <email@example.com> 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.
> 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 <firstname.lastname@example.org> writes:
> > > Greg Stein <email@example.com> 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