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 http://svn.apache.org/repos/asf/, 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 handy. > 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: /incubator/directory/branches /incubator/directory/tags /incubator/directory/trunk /incubator/directory/site If you have subprojects, then you'd add a layer: /incubator/directory/subproject/branches /incubator/directory/subproject/tags /incubator/directory/subproject/trunk /incubator/directory/site Of course, you can start without subprojects, reorganize later as needed. The Apache Commons project keeps its PMC-wide status file at: /commons/STATUS 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: http://svnbook.red-bean.com/book.html#svn-ch4-sect7.1 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. Cheers, -g -- Greg Stein, http://www.lyra.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
