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

Re: svn commit: rev 1957 - trunk/subversion/include trunk/subversion/libsvn_wc

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-05-15 00:41:24 CEST

Greg Stein <gstein@lyra.org> writes:

> On Tue, May 14, 2002 at 04:35:33PM -0500, kfogel@tigris.org wrote:
> >...
> > +++ trunk/subversion/include/svn_types.h Tue May 14 16:35:18 2002
> > @@ -177,6 +177,12 @@
> > /* Set to either TRUE or FALSE if we want a file to be executable or not. */
> > #define SVN_PROP_EXECUTABLE SVN_PROP_PREFIX "executable"
> >
> > +/* Set to either TRUE or FALSE to indicate if a file is a module.
> > + ### This should be automatically inherited from the parent
> > + directory... which raises the general issue of property
> > + inheritance. */
> > +#define SVN_PROP_MODULE SVN_PROP_PREFIX "module"
> I highly disagree that this should be inherited.
> The concept of a "directory full of module descriptions" is only a
> convention. I do not believe we need to formalize that, or add in entire new
> concepts of property inheritance to support anything more than that.

I objected too, only because property inheritance is a bitch to
implement. But Karl believes that users might forget to set the
svn:module property on new modules, because they'll often be adding
the module to a directory full of them. Then they'll expect something
to happen, and nothing will happen. I'll Karl him speak for himself. :-)

> For example, it might be really neat to drop a special developer's module
> file into tools/dev/. Regular Joe off the street just grabs the /trunk or
> whatever and is done.

Certainly, Karl's idea doesn't *force* us to put all modules in one
place. We still plan to allow single module files to live anywhere in
the whole repository.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 15 00:44:36 2002

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.