[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-25 22:45:31 CET

On Dec 22, 2004, at 1:01 PM, Justin Erenkrantz wrote:

> --On Tuesday, December 21, 2004 9:59 AM -0600 Ben Collins-Sussman
> <sussman@collab.net> wrote:
>
>> $ 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?
>
> No, why would you think they are special? Any WebDAV client would see
> them as well.
>

Generic WebDAV clients are irrelevant. Sure, when they do a PROPFIND,
they'll see all sorts of properties: both dead and live ones, and a
bunch of svn-specific ones. It's no surprised for a particular DAV
server to have its own custom props.

But my point is that the svn commandline is *not* a generic webdav
client. It shouldn't be exposing webdav-specific concepts (or
properties) to users. The 'svn propFOO' set of subcommands only deal
with dead props, and nothing else. Users should never witness the
existence of ra_dav's private caching mechanism (wcprops), nor should
it be able to view webdav 'live' props. (Those are automatically
converted into 'entryprops' that live in .svn/entries, visible via 'svn
info'.)

svn concepts come first. WebDAV concepts should remain hidden and be
mapped to "under the hood", not publically.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 26 23:34:18 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.