DAV props -- how to proceed?

[Ben Collins-Sussman <su...@collab.net>]

WebDAV/deltaV has the same notion of metadata that Subversion
does... and even calls them "properties" too.

The difference is that deltaV has two subcategories of properties:
"live" props are completely defined by the server, and "dead" props
are defined by users.  "live" props are read-only to users.

Let's look at requirements.

 * Requirement #1: the dav layer has a lot of bookkeeping to do; it
   wants to store its own 'live' props on *every* version of each file
   and directory in the repository.

 * Requirement #2: the dav layer needs to store contextual properties
   in the working copy, such as which activity to commit to, and the
   versioned-resource-url of each working copy object.

     ==> This requirement has already been solved by giving each RA
     layer the ability to store "secret" properties called "wc
     props.".  They are completely invisible to the user.

 * Requirement #3: the repository itself wants to automatically attach
   properties to certain things (like transactions and revisions.)  It
   has no notion, however, of "live" vs. "dead".  Even properties it
   creates, like a revision datestamp, can be edited by any user of
   libsvn_fs. 


So here are the questions on my mind:

  * Are users supposed to see all the 'live' props (from requirement #1)
    inserted by the DAV layer?  I don't think they should just
    casually show up in the working copy when a user types "svn
    proplist foo.c".

  * Assume we want to hide them.  Fine.  Then they'll be stored as
    secret "wc props".  But that means *every* RA layer needs to
    filter them out when reading the repository (so they can be stored
    differently on the client side.)  Isn't this icky?

  * To what extent should live props be visible at all?  Is there ever
    a case where we would want to augment 'svn proplist' to show us
    all of the hidden, read-only live props?


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: DAV props -- how to proceed?

[Ben Collins-Sussman <su...@collab.net>]

Joe Orton <jo...@btconnect.com> writes:

> On Fri, Jul 06, 2001 at 05:40:39PM -0500, Ben Collins-Sussman wrote:
> > Ben Collins-Sussman <su...@collab.net> writes:
> > 
> > >   * Assume we want to hide them.  Fine.  Then they'll be stored as
> > >     secret "wc props".  But that means *every* RA layer needs to
> > >     filter them out when reading the repository (so they can be stored
> > >     differently on the client side.)  Isn't this icky?
> > 
> > Of course, another possibility is that we could make libsvn_wc
> > automatically filter live vs. dead props, and store them in different
> > places.  But that's also kinda icky.
> 
> Ah, I was going to avoid this issue completely*, and just map SVN
> user-supplied properties (from 'propset' or whatever) into (dead)  
> properties on the DAV server in the 'SVN:custom' namespace. Then, ra_dav
> ignores all live and dead properties when fetching from the server
> except those in 'SVN:custom' and the other ones it knows about.


Well, that's certainly avoiding the issue!  Still, if you can get all
user props moving both ways over the network, we'll love you.  The
problem can be decided upon later.

What's going on here is that subversion filesystem just provides
"properties" is the most general sense.  And now our WebDAV layer is
slowly creeping... creeping... creating distinct categories of
properties that all the rest of subversion has to deal with.  I want
to stop implicit Policy-Creep, and instead *decide* on a good policy.

But please implement now.  We'll settle policy next week.  :-)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: DAV props -- how to proceed?

[Joe Orton <jo...@btconnect.com>]

On Fri, Jul 06, 2001 at 05:40:39PM -0500, Ben Collins-Sussman wrote:
> Ben Collins-Sussman <su...@collab.net> writes:
> 
> >   * Assume we want to hide them.  Fine.  Then they'll be stored as
> >     secret "wc props".  But that means *every* RA layer needs to
> >     filter them out when reading the repository (so they can be stored
> >     differently on the client side.)  Isn't this icky?
> 
> Of course, another possibility is that we could make libsvn_wc
> automatically filter live vs. dead props, and store them in different
> places.  But that's also kinda icky.

Ah, I was going to avoid this issue completely*, and just map SVN
user-supplied properties (from 'propset' or whatever) into (dead)  
properties on the DAV server in the 'SVN:custom' namespace. Then, ra_dav
ignores all live and dead properties when fetching from the server
except those in 'SVN:custom' and the other ones it knows about.

joe

* = hide my head in the sand

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: DAV props -- how to proceed?

[Ben Collins-Sussman <su...@collab.net>]

Ben Collins-Sussman <su...@collab.net> writes:

>   * Assume we want to hide them.  Fine.  Then they'll be stored as
>     secret "wc props".  But that means *every* RA layer needs to
>     filter them out when reading the repository (so they can be stored
>     differently on the client side.)  Isn't this icky?

Of course, another possibility is that we could make libsvn_wc
automatically filter live vs. dead props, and store them in different
places.  But that's also kinda icky.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org