- add more rationale for using svn.

- add discussion section.
- change procedure to create a single repository, add conversion script.
- require python-cvsroot to be preserved forever.
This commit is contained in:
Martin v. Löwis 2005-08-07 14:17:43 +00:00
parent ac8c835cce
commit 5d09843254
1 changed files with 87 additions and 27 deletions

View File

@ -37,7 +37,12 @@ improvements are:
directories, while keeping the history of these files.
- support for change sets (sets of correlated changes to multiple
files) through global revision numbers.
files) through global revision numbers. Change sets are
transactional.
- atomic, fast tagging: a cvs tag might take many minutes; a
subversion tag (svn cp) will complete quickly, and atomically.
Likewise, branches are very efficient.
- support for offline diffs, which is useful when creating patches.
@ -75,8 +80,7 @@ executed. The steps are elaborated upon in the following sections.
3. 24 hours after the last commit, download the CVS repository.
4. Convert the CVS repository into two Subversion repositories, one
for Distutils and one for Python.
4. Convert the CVS repository into a Subversion repository.
5. Publish the repositories with write access for committers, and
read-only anonymous access.
@ -93,16 +97,6 @@ need to provide a password. This mechanism should be used, at least
initially, for the Python CVS as well, since various committers also
have a username/password pair for the www SVN repository already.
Alternatives to password-based access include:
- Subversion over SSH, using SSH key pairs. This would require
committers to be given accounts on the machine, which currently is
ruled out by the administration policy of svn.python.org.
- Subversion over WebDAV, using SSL client certificates. This would
work, but would require to administrate a certificate authority.
Downloading the CVS Repository
------------------------------
@ -115,14 +109,23 @@ after the repository freeze before the tarball can be picked up. It
should be verified that the last commit, as recorded on the
python-commits mailing list, is indeed included in the tarball.
After the conversion, the converted CVS tarball should be kept
forever on www.python.org/archive/python-cvsroot-<date>.tar.bz2
Converting the CVS Repository
-----------------------------
The Python CVS repository contains two modules: distutils and python.
Keeping them together will produce quite long repository URLs, so it
is more convenient if the Python CVS and the Distutils CVS are
converted into two separate repositories.
The python module is further structured into dist and nondist,
where dist only contains src (the python code proper). nondist
contains various subdirectories.
These should be reorganized in the Subversion repository to get
shorter URLs, following the <project>/{trunk,tags,branches}
structure. A project will be created for each nondist directory,
plus for src (called python), plus distutils. Reorganizing the
repository is best done in the CVS tree, as shown below.
Fsfs should be used as the repository format (requires Subversion
1.1). Fsfs has the advantage of being more backup-friendly, as it
@ -130,21 +133,39 @@ allows incremental repository backups, without requiring any dump
commands to be run.
The conversion should be done using the cvs2svn utility, available
e.g. in the cvs2svn Debian package. The command for converting the
Python repository is ::
e.g. in the cvs2svn Debian package. As cvs2svn does not currently
support the project/trunk structure, each project needs to be
converted separately. To get each conversion result into a separate
directory in the target repository, svnadmin load must be used.
In summary, the conversion script is::
cvs2svn -q --encoding=latin1 --force-branch=cnri-16-start \
--force-branch=descr-branch --force-branch=release152p1-patches \
--force-tag=r16b1 --fs-type=fsfs -s py.svn.new python/python
The command to convert the distutils repository is ::
cvs2svn -q --encoding=latin1 --fs-type=fsfs -s dist.svn.new python/distutils
#!/bin/sh
rm cvs2svn-*
rm -rf python py.new
tar xjf python-cvsroot.tar.bz2
rm -rf python/CVSROOT
svnadmin create --fs-type fsfs py.new
mv python/python python/orig
mv python/orig/dist/src python/python
mv python/orig/nondist/* python
# nondist/nondist is empty
rmdir python/nondist
rm -rf python/orig
for a in python/*
do
b=`basename $a`
cvs2svn -q --dump-only --encoding=latin1 --force-branch=cnri-16-start \
--force-branch=descr-branch --force-branch=release152p1-patches \
--force-tag=r16b1 $a
svn mkdir -m"Conversion to SVN" file:///`pwd`/py.new/$b
svnadmin load -q --parent-dir $b py.new < cvs2svn-dump
rm cvs2svn-dump
done
Sample results of this conversion are available at
| http://www.dcl.hpi.uni-potsdam.de/python/
| http://www.dcl.hpi.uni-potsdam.de/distutils/
http://www.dcl.hpi.uni-potsdam.de/pysvn/
Publish the Repositories
@ -169,6 +190,45 @@ interface can be removed from the project page; the repository itself
remains available. If desired, write access to the python and
distutils modules can be disabled through a CVS commitinfo entry.
Discussion
----------
Several alternatives had been suggested to the procedure above.
The rejected alternatives are shortly discussed here:
- create multiple repositories, one for python and one for
distutils. This would have allowed even shorter URLs, but
was rejected because a single repository supports moving code
across projects.
- Nick Bastin has offered to host a Perforce repository, instead
of using subversion. Details of that offer are not clear yet.
- Several people suggested to create the project/trunk structure
through standard cvs2svn, followed by renames. This would have
the disadvantage that old revisions use different path names
than recent revisions; the suggested approach through dump files
works without renames.
- Several people also expressed concern about the administrative
overhead that hosting the repository on python.org would cause
to pydotorg admins. As a specific alternative, BerliOS has been
suggested. The pydotorg admins themselves haven\'t objected
to the additional workload; migrating the repository again if
they get overworked is an option.
- People have expressed dislike of the basic auth (username/password)
authentication. Two alternatives have been suggested:
* Subversion over SSH, using SSH key pairs for a single Unix
account, restricted to the execution of svnserve. The pydotorg
admins have ruled out creation of one account per committer;
whether a single account would be acceptable is not yet
decided.
* Subversion over WebDAV, using SSL client certificates. This would
work, but would require to administrate a certificate authority.
Copyright
---------