[Python-Dev] PEP: Migrating the Python CVS to Subversion

["Martin v. Löwis"]

Barry Warsaw wrote:
 > I know that SF has promised svn access to projects for a long time now,
> but I haven't heard anything from them in a long time.  It's listed
> under their "Strategic Projects" but the last update to that news item
> was back in April.  Question: do we wait for SF to make the service
> available (after getting more up-to-date status and a realistic
> timetable), or do we go straight to svn.python.org?

My proposal is to go straight to svn.python.org, for two reasons:
- It might well be 2006 before they update the status and provide
  a realistic timetable. It's not that I lost faith into SF, but
  they seem to be continually overworked (as anybody), so anything
  that is not *really* essential to the operation of the service
  (such as support for subversion) has to wait "until we have
  time" -- which means it has to wait forever. Remember the plan
  to provide shell access to the project admins on the CVS server?
- They currently have a separate anonymous access for CVS which
  is behind the real CVS, for load sharing reasons. They also had
  severe performance issues in the past. It might be that we
  also get performance problems, but we only need to support a
  single project (or two if you count pydotorg) on Subversion,
  not thousands of them. So our load evolution is much more
  predictable.

>>1. Assign passwords for all current committers for use on svn.python.org.
>>   User names on SF and svn.python.org should be identical, unless some
>>   committer requests a different user name.
> 
> 
> We've been going with firstname.lastname (with some exceptions -- hi
> Aahz! :) for the current svn access.  Is it better to stay with that
> convention or to maintain consistency with SF's CVS committer names? 
> Maybe the latter for revision history consistency.

It's also a convenience issue, and has social aspects. For example,
firstname.lastname does not work quite well for me, either
(martin.v.loewis or martin.von.loewis would work better; likewise
guido.van.rossum?), other users prefer not to use their "true"
real name (e.g. tim_one vs. tim.peters).

Another issue is password assignment - currently, users cannot choose
their passwords on svn.python.org, right?

> We can probably play games with the various CVS hooks to disable all
> checkins during this time.  We might also want to disable the u/i access
> to CVS at the same time.

That should be tested in advance, of course.

>>4. Convert the CVS repository into two subversion repositories,
>>   one for distutils and one for Python.
> 
> 
> Do we also want to split off nondist and encodings?

Well, encodings is empty right now, so that might be a good idea.
Technically, I would just move the files in the CVS repository before
conversion.

As for nondist: how precisely would you do that? Make it a separate
repository? If so, where? I could envision a "/projects" repository,
that has the current nondist.

> Note that we might want to provide different access permission to
> different parts of the repository (but I think we can do that even if we
> don't split those off into separate repos).

I don't know how cvs2svn supports it, but one option would be to
revert the trunk/ structure in /projects, so you get

http://www.python.org/projects/peps/trunk
http://www.python.org/projects/peps/tags
http://www.python.org/projects/peps/branches
http://www.python.org/projects/sandbox/trunk
http://www.python.org/projects/sandbox/tags
http://www.python.org/projects/sandbox/branches

Then you could give different access to peps and to sandbox.
Perhaps there isn't even a need for tags/branches on PEPs? Or
we put everything in nondist into /projects, and then put
tags + branches as siblings (so only people with write access
to tags could create them)?

Regards,
Martin