Sheesh. From watching our mails, you wouldn't know that Ben and I are
sitting right next to each other. :)
Ben Collins-Sussman <email@example.com> writes:
> 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 <firstname.lastname@example.org> 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 <email@example.com> writes:
> > > Greg Stein <firstname.lastname@example.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