httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: Web server docs proposal (take n)
Date Tue, 30 May 2000 21:11:42 GMT
On Tue, 30 May 2000, Greg Stein wrote:

> On Tue, 30 May 2000, Marc Slemko wrote:
> > On Mon, 29 May 2000, Rodent of Unusual Size wrote:
> >...
> > > o Why separate modules rather than finding a way to let these
> > >   docco-only people work only in the htdocs/ subtree?  Because of
> > >   the mailing list issue, because this is how we've historically
> > >   managed disjoint committer lists, because this is how other
> > >   ASF projects seem to be handling subprojects, and because this
> > >   doesn't require futzing with the CVS scripts that affect *all*
> > >   of the ASF projects.
> > 
> > Your use of the word "module" is very confusing.  A "module", as
> 
> He means /home/cvs/httpd-docs-1.3/ and /home/cvs/httpd-docs-2.0/

I know what he means.  However, he is trying to suggest that somehow 
that is a "module" and is specical to CVS.  That is not what a CVS 
module is.  The world module has a very specific meaning.

> 
> > defined by CVS, is either an entry in the modules file or a particular
> > path to the root of a tree of files.  So the docs are already their
> > own module.  And you can add an entry to the modules file just fine
> > so you can do a "cvs checkout httpd-docs-1.3" and get apache-1.3/htdocs.
> > So there is no change required to put the docs in their own module.
> > They are there.
> > 
> > There is nothing required to allow other people to commit to only the
> > htdocs subdirectory other than adding them all to a group and chgrping
> > that subdirectory.
> > 
> > The mailing list issues aren't too had to handle, especially if you
> > subscribe to the idea that if docs and code change in one commit, then
> > they should be mailed together because they are related.  Then you just
> > need a tiny little filter getting mail to the main CVS commit list and
> > forwarding anything that includes docs changes to the random other docs
> > only list.
> 
> Ken is operating from a known standpoint: create new top-level modules.
> All this mucking around could create problems within the repository. For
> example, consider the case where an "httpd" cvs user commits to
> apache-1.3/htdocs/ and it changes the group setting. Oops! Now the docs
> people cannot change that.
> (dunno if FreeBSD has a "sticky group" bit like Linux)

That is how it already has to work!  There is nothing that tells
CVS to magically use a certain group for a certain subdirectory as
things are now; CVS knows nothing about the OS groups.  The OS does
it.  There is nothing different between having cvsroot/foo and
cvsroot/bar and having cvsroot/foo and cvsroot/foo/bar as far as
how groups work.

Once you understand how CVS is doing things anyway, it really isn't 
a matter of any "mucking around".  The only "mucking around" is with 
some locally hacked up scripts to change how they mail stuff, or 
just leave that out entirely and use a procmail filter or something.

> 
> -1 on trying to create new operational modes like Marc suggests. I've
> previously stated +1 on Ken's approach.

It isn't a "new operational mode" once you understand how CVS works anyway.

> 
> > Are you certain that commits that commit to both top level directories at
> > once will be mailed out properly anyway?
> 
> Nobody does that today, so it is not a requirement for tomorrow. If it
> works, then great. Otherwise, it just doesn't matter.

One of the things stated earlier was that people who want to can
just check the docs tree out in a htdocs subdirectory of their
working directory, and act like it was never changed.  Committers
should be committing docs changes to go along with their code at
the same time they do the code.  If they do that, then they will
try to commit to two "top level modules" at once.  cvs may separate
the commits enough by itself to avoid this problem.  I don't know.
If it doesn't, then you will end up with the log being sent to the
list as defined by the first file being committed.  And that isn't
very good.

It _IS_ a requirement for tomorrow because we are now taking two trees
that are intrinsically related and pulling them apart, then saying that if
people want them together they can do it themself.  The consequences of
doing that have to be considered.  I do not consider it to be a good
tradeoff to require committers who are committing code and docs changes to
have to go to two separate places and do two separate commits, etc. That
is the completely wrong direction.


Mime
View raw message