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.
