Martin v. Löwis wrote:
Tim Peters wrote:
Ah, before I forget, "single repository" has worked very well for Zope (which includes top-level Zope2, Zope3, ZODB, ZConfig, zdaemon, ... projects):
Long URLs don't really get in the way in practice (rarely a need to type one after initial checkout; even "svn switch" is usually just a tail-end cmdline edit starting from a copy+paste of "svn info" output).
That would indeed give conversion problems:
Nah
cvs2svn automatically generates tags/trunk/branches in the root, with the original CVS modules below; there is a single space for tags and branches (as is in the original CVS repository).
I would see two possible conversion procedures: 1. convert the modules one-by-one, adding to the same repository. I.e. python would get all the small revision numbers, then peps, then sandbox, and so on. Cross-module tags would not be supported (but likely don't exist in the first place), and the revision number would not increase in historical order. 2. convert the entire CVS, then rearrange things through svn move. This would be tedious to do (atleast for tags/branches), and it would cause all files to be renamed right from the scratch (some svn clients fail to display history past moves).
You reminded me of another reason why I used a custom conversion script. :) I did convert projects individually. I told cvs2svn to just create dump files. I then used svnload to load the dump files myself so that I could make each project a top-level directory with it's own trunk, branches and tags. I'd be happy to share my scrips, although there's nothing all that complicated about them.
So for all who would prefer to see a single repository, could somebody please 1. state how precisely the repository should be organized (with exact URLs on svn.python.org - eg. which of the non-dist directories becomes toplevel, which ones get their own tags/branches/trunk, etc).
I'm not close enough to the Python repo to offer much of an opinion other than: - IMO, a single repository is good - The repository should be orgabized by "projects", where separate projects reflect more or less independent development efforts with their own teams and schedules. (Maybe Python doesn't have many of these.)
2. state how the conversion should be performed
Once you decide what the projects are, I suggest converting each project separately. I'd be happy to share my scrips and experenice, although, as Tim noted I'll be off-line for two or three weeks starting in the next few days. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org