[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: propget bug?

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-12-29 04:37:41 CET

On Dec 28, 2004, at 7:24 PM, kfogel@collab.net wrote:

> Ben Collins-Sussman <sussman@collab.net> writes:
>> $ svn propget svn:wc:ra_dav:version-url README
>> /repos/svn/!svn/ver/12286/trunk/README
>> ...uhhh, I thought 'wcprops' (just like 'entryprops') were things only
>> understood internally by libsvn_wc.
>> My understanding is that our UI for manipulating properties are only
>> for 'normal', user-controlled versioned props. I think this is a bug,
>> and should be filed, yeah?
> I'm not so sure it's a bug. It's not like the property shows up in
> 'proplist' -- it only appears if you ask for it by name. And if you
> know enough to ask for it by name, why shouldn't Subversion show it?

Because to subversion, a "property" is strictly defined as only those
chunks of metadata explictly created (or at least manipulatable) via
'svn propset'.

Under the hood, we just happened to overload the editor's property
mechanisms to receive and store other forms of metadata: .svn/entries
junk coming from the server, and caching metadata generated by ra_dav.
We could have implemented these other forms of internal metadata in any
number of ways. Instead, we decided to call everything "properties":
"entry properties" and "wc properties". It's cute that libsvn_wc has
a notion of "three kinds of properties". But for the person using the
svn client, those categories don't exist: it's all unknown machinery.
To that person, there's only one type of property in the whole
universe: the kind you create by running 'svn propset'. I think it's
wrong for 'svn propget' to accidentally reveal random hidden guts.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 29 04:39:52 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.