- 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:
parent
ac8c835cce
commit
5d09843254
114
pep-0347.txt
114
pep-0347.txt
|
@ -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
|
||||
---------
|
||||
|
||||
|
|
Loading…
Reference in New Issue