Just to follow up:
Ben asked the question: does the user see these svn-specific
properties when she lists properties? As in "svn proplist"?
I think the answer is, yes she can, but not necessarily by default.
If not by default, then they are shown along with all other properties
when when a `--long' or `--all' flag is passed.
I guess my reasoning is, we shouldn't create a duplicate mechanism
when we already have the mechanism we need. Nor should we make this
information completely hidden from the user, if they really want to
see it. It just shouldn't distract them from the data they care
about, that's all.
-K
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