directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Rethink Subversion
Date Tue, 25 Nov 2003 06:07:49 GMT
On Mon, Nov 24, 2003 at 06:09:58PM -0500, Noel J. Bergman wrote:
> > Here is how I would like to proceed
> > I have brought down our CVS tarball from sourceforge.
> > I will create a local SVN report and use the cvs2svn
> > to get the initial SVN repo created.
> Sounds good to me, although I am not a Subversion expert.  The more we can
> keep our CVS history, the better.

Yup, this is the basic approach. You'll want to produce a dump file which
can then be loaded into the main ASF repos. For testing, you can load it
into a private repos.

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 will then run the conversion script to change the
> > package names and add the apache license header to
> > the files.
> Sounds correct.  I don't know if the new licenses are close enough that we
> can start using the short form of the new Apache Software License version 2.

The new license hasn't been approved for use yet. Therefore, the 1.1
license must be used, which also implies a full copy within each file.

> > I will probably only do this with one or two of the root level
> > directories.  Once it looks like everything works, we will do
> > a code freeze, and run the process for the entire CVS tarball,
> > and bring the new subversion repo in.
> You might want to take a look at, which is
> the official ASF Subversion repository.  As I understand it, there will only
> be one repository, rather than one per project.

Correct. Given the renames and shifting of projects that occurs, having
everything in one repository where we can track those moves will be very

> So we'll need to be told
> where to put our directory structure.  As a guess:
>   /incubator/directory/branches/sub-project
>   /incubator/directory/tags/sub-project
>   /incubator/directory/trunk/sub-project
>   /incubator/directory/site

What "sub-project" are you referring to? Isn't the Directory just a single
project? Shouldn't it be?

> but one of the Subversion folks could recommend:
>   /incubator/directory/sub-project/branches
>   /incubator/directory/sub-project/tags
>   /incubator/directory/sub-project/trunk

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.

Assuming you don't have any subprojects, then you'd have:


If you have subprojects, then you'd add a layer:


Of course, you can start without subprojects, reorganize later as needed.

The Apache Commons project keeps its PMC-wide status file at:


Codebases within Commons have a STATUS file located in their trunk so that
it gets versioned along with the code development.

> instead.  I don't know the Best Practice for laying out a Subversion
> repository.  See also:

See above :-)

> Infrastructure will have to set up access and/or provide instructions for
> the temporary mechanism.  We have mod_authz_svn setup, and controlled by a
> master file.  I'm fairly sure that we are not going to want every Committer
> editing that file.  And I am hoping that we will have SSL to protect the
> passwords soon.

No... it 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. Currently, there are four PMCs
who (plan to) use the SVN repos: Commons, Incubator, XML, and Jakarta.
IMO, our mod_authz_svn config file should reflect that breakdown; I don't
think we should have different sets of access/responsibility.


Greg Stein,

View raw message