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

Re: Change #3: New "WC" properties.

From: Karl Fogel <kfogel_at_galois.collab.net>
Date: 2001-01-23 15:21:04 CET

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 <sussman@newton.collab.net> writes:
> Greg Stein <gstein@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. :)
Received on Sat Oct 21 14:36:19 2006

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.