directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <>
Subject RE: Rethink Subversion
Date Tue, 25 Nov 2003 08:15:01 GMT
> 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

	--- Noel

View raw message