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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
