> Be wary of the branch/tag support. In general, it works just fine. If > you've done some complicated branch/tag funkiness, then you may run > into some issues. I don't believe that we have much to worry about in the current CVS. > What "sub-project" are you referring to? Isn't the Directory just > a single project? Shouldn't it be? The directory project will have multiple related deliverables. We've got the LDAP server, we'll have JNDI code, we'll have Object and State factories for useful things, and we agreed that we would be language-agnostic, so we could have other codebases that are closely related. > This is the preferred form for any codebase release. i.e. every codebase > should have branches/tags/trunk. The site area does not require branching > or tagging, so it can remain a sibling. > /incubator/directory/subproject/branches > /incubator/directory/subproject/tags > /incubator/directory/subproject/trunk > /incubator/directory/site Talking with Greg online, he explained that the SvnBook is currently "wrong" in the section I read, and that the above is the desired layout. What we call a "subproject" above would be a "codebase" -- something that we plan to label and release separately. Anything that we would version independently. The recommended layout is tied to release management. > [the mod_authz_svn configuration] should be edited only by a subset > at this point, similar to editing CVSROOT/avail. (e.g. infra + PMC chairs) > I would also suggest that we perform access control along the lines of > PMCs, rather than subproject granularity. As I mentioned online, I can see reasons for wanting to control who has access to partitions within the repository. For example, we might want to grant someone commit access to the site docs without granting access to the code. I do see your point about every PMC member having access across their entire subtree(s), but that's easy enough to do. And we still have umbrella projects, where we don't give everyone commit access to every project in the umbrella. --- Noel