You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@newton.collab.net> on 2001/01/20 02:18:49 UTC
Change #3: New "WC" properties.
Change #3: New "WC" properties.
Status Quo:
Properties attached to objects in the repository also appear in the
WC. Similarly, properties added to WC objects get committed to the
repository.
Proposed Change:
Create a new class of properties that *only* exist in the WC.
These properties are stored for the benefit of RA layers. We add
new editor functions:
set_wc_dir_props (dir_baton, name, val)
set_wc_file_props (file_baton, name, val)
If driving an editor: if WC props exist for the object you're
describing, you *must* send them via these functions.
If implementing an editor: if you receive WC props, you *must*
store them somewhere.
Rationale:
The idea here is that RA layers often need to store and retrieve
RA-specific information in the working copy. This is "out of band"
data" that is irrelevant to the repository.
In the case of ra_dav, these properties are actually the versioned
resource URLs. In the case of ra_local, we may store
authentication information this way (instead of using a .cvspass
file). There may be other ra layers someday that need to store
private data in the same way, so we now have a general method for
doing so.
Note: this is the only editor change that *truly* has nothing to
do with "describing a tree change", which should make all of us
raise our collective eyebrows suspiciously. However, I don't think
the "plug n' play" vision of editors is lost here, although we're
skirting the near the line.
Re: Change #3: New "WC" properties.
Posted by Karl Fogel <kf...@galois.collab.net>.
Let's stick with "wc". Even a versioned file system is still a
working copy, if it's possible to checkout that fs to some other
location. :-)
The problem with calling them "local" properties is that "local" needs
more context before it means something -- local to what? The
repository? The client? The network connection? "WC" is
unambiguous.
-K
Ben Collins-Sussman <su...@newton.collab.net> writes:
> Greg Stein <gs...@lyra.org> writes:
>
> > On Sun, Jan 21, 2001 at 11:17:20PM +0100, Branko Cibej wrote:
> > > Ben Collins-Sussman wrote:
> > >
> > > > Note: this is the only editor change that *truly* has nothing to
> > > > do with "describing a tree change", which should make all of us
> > > > raise our collective eyebrows suspiciously. However, I don't think
> > > > the "plug n' play" vision of editors is lost here, although we're
> > > > skirting the near the line.
> > >
> > > One question comes to mind: what about clients that /don't/ use a
> > > working copy? Kevin's versionable fileystem would be one.
> >
> > What about them?
> >
>
> By definition, any "layer" that implements an editor must have a
> filesystem of *some* kind. (Even an XML file counts as some kind of
> filesystem, right?)
>
> Therefore if WC properties are received by an editor, we know that the
> editor will be able to store them somehow. And if this layer needs to
> drive an editor, it can retrieve them as well.
>
> The name is misleading here -- we're calling them "WC" properties, but
> that doesn't mean you need a working copy. It just means that they're
> properties that belong to the RA layer, and don't exist in the
> repository. We originally called them "local" properties, but we
> thought "WC" properties was clearer. Maybe not. :)
Re: Change #3: New "WC" properties.
Posted by Ben Collins-Sussman <su...@newton.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> On Sun, Jan 21, 2001 at 11:17:20PM +0100, Branko Cibej wrote:
> > Ben Collins-Sussman wrote:
> >
> > > Note: this is the only editor change that *truly* has nothing to
> > > do with "describing a tree change", which should make all of us
> > > raise our collective eyebrows suspiciously. However, I don't think
> > > the "plug n' play" vision of editors is lost here, although we're
> > > skirting the near the line.
> >
> > One question comes to mind: what about clients that /don't/ use a
> > working copy? Kevin's versionable fileystem would be one.
>
> What about them?
>
By definition, any "layer" that implements an editor must have a
filesystem of *some* kind. (Even an XML file counts as some kind of
filesystem, right?)
Therefore if WC properties are received by an editor, we know that the
editor will be able to store them somehow. And if this layer needs to
drive an editor, it can retrieve them as well.
The name is misleading here -- we're calling them "WC" properties, but
that doesn't mean you need a working copy. It just means that they're
properties that belong to the RA layer, and don't exist in the
repository. We originally called them "local" properties, but we
thought "WC" properties was clearer. Maybe not. :)
Re: Change #3: New "WC" properties.
Posted by Greg Stein <gs...@lyra.org>.
On Sun, Jan 21, 2001 at 11:17:20PM +0100, Branko Cibej wrote:
> Ben Collins-Sussman wrote:
>
> > Note: this is the only editor change that *truly* has nothing to
> > do with "describing a tree change", which should make all of us
> > raise our collective eyebrows suspiciously. However, I don't think
> > the "plug n' play" vision of editors is lost here, although we're
> > skirting the near the line.
>
> One question comes to mind: what about clients that /don't/ use a
> working copy? Kevin's versionable fileystem would be one.
What about them?
It isn't like we can think about everything under the sun. I'd rather put my
brain cycles elsewhere. When somebody wants to use something other than the
WC, then we can truly test the plug-n-play. Personally, I'm not too
interested in heavy thought experiements about the issue.
Feel free for yourself, of course :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Change #3: New "WC" properties.
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
> Note: this is the only editor change that *truly* has nothing to
> do with "describing a tree change", which should make all of us
> raise our collective eyebrows suspiciously. However, I don't think
> the "plug n' play" vision of editors is lost here, although we're
> skirting the near the line.
One question comes to mind: what about clients that /don't/ use a
working copy? Kevin's versionable fileystem would be one.
--
Brane �ibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/