[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: Greg Stein <gstein_at_lyra.org>
Date: 2002-05-15 01:52:40 CEST

On Tue, May 14, 2002 at 06:18:09PM -0500, Karl Fogel wrote:
> Greg Stein <gstein@lyra.org> writes:
> > > +/* 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.
> What I'm afraid of is people add a new module file to a dir full of
> modules files, but then it doesn't behave like a module because they
> forgot to add the property.

While it is nice to do some hand-holding for users, I don't think this is
one of those cases, especially given the requirement for property
inheritence to get this implemented.

> Yeah, but they added it in a directory called "modules", one can
> hardly blame them... :-)

Heh. But the failure mode is obvious. They do:

$ svn co http://svn.collab.net/repos/svn/modules/svn-docs

And they get a file called svn-docs. Nothing else. "D'oh! I forgot to add
the svn:module property!" Then it works great.

> I don't think its absolutely necessary, but so far I see only plusses
> and no minuses (except implementation time, and I wasn't saying we
> should do it now).

As long as you can sign up for prop inheritance to be post-1.0, then I'm
fine with it. We can simply defer the discussion until then :-)

[ I'm not strictly against the concept, just against doing it for 1.0 ]

> > 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.
> Erp. I don't understand this example.

I re-read it after posting and realized the same.

Let's say all the developers keep finding they have a particular set of
directories that they use, which is quite different from Regular Joe on the
street. So the developers go and build themselves a modules file and drop
that one file into tools/dev/, and use it for their checkouts.

Regular Joe has different needs, and doesn't know better, so they just grab

Of course, as Ben pointed out, nothing in your work/docs so far precludes
the above scenario (a single module file hanging out in an arbitrary
location). *BUT* you premised the inheritance "requirement" on the notion of
having directories full of these things. I'm not sure that is going to be
entirely true. That was just kind of an off-the-cuff organization for them
that I mentioned when we were talking about it. Out there in the "real
world", people might find a better way to keep module files around, rather
than glomming all possible files into one directory somewhere.


Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 15 01:50:59 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.