Hi Werner. Thanks for creating the conversion cookbook. On 2007-01-13 00:19+0100 Werner Smekal wrote:
> I ran through the source forge documentation about the cvs to svn > conversions and I tested practically all steps. I made a copy of the > whole repository, converted it, and uploaded it to my server, but > stopped the import since it just took too long (it finished 256 > revisions of 7586) - you can see this historic plplot revision here: > http://svn.miscdebris.net/plplot/trunk/plplot/ . That's already an interesting result. Just have a look at what is (not) in bindings to get a feel for what PLplot was like in that early (4.99c) era. Is this long "import" process the step that takes so long in the official SourceForge process? They mention 24-hours or more to complete the task. > > Anyway, below you'll find the cookbock for this process. Rather straight > forward. We also need to agree, when to do it and how. My proposal would > be to do it after the next release. Nobody should commit than something > for some days, until it is imported into the sf-svn repository and > tested/compared. If the conversion was done satisfactorily we should > than use svn exclusively. > > What do you think about that? Before we do the conversion to subversion at SourceForge, I think we should at least provide an opportunity for PLplot developers to get familiar with svn. Could you (or somebody else) make a complete test PLplot subversion repository available for us to play with? Alternatively, could you add instructions (probably about the exact "import" step that must be done) to your cookbook about how each of us could set up our own local test PLplot subversion repository? Some of the tests I would like to do for such a test repository are whether we could reproduce a number of our historical source releases and our complete historical ChangeLog (currently created by cvs2cl from our CVS repository) from a test subversion repository. I think such tests are essential because I have already had one bad experience with our current CVS repository; it turned out to be completely broken for branches until a lot of maintainence (re-deleting a whole bunch of files which kept "rising from the dead") was done. So there still may be something non-standard in our CVS that will cause the conversion process to give bad results for some epochs. Reproduction of some of our historical tarball releases and our complete ChangeLog would help to satisfy me on this issue. In answer to your question, I think we should go ahead with the "conversion to subversion", but only after the next stable release (i.e., 5.8.0). That gives the current shakedown process for our new CBS (i.e., the current on-going set of 5.7.x development releases) time to complete without interference from a repository format switch. If there is a well-known deadline for the conversion after the 5.8.0 release, that should give plenty of lead time (see below) for our developers to play with subversion and do all the tests that they think our necessary. Furthermore, if we do the conversion post-5.8.0, then that allows us to use the 5.9.x development cycle in part for working out any script issues (remember, many of our release scripts currently depend on cvs). By the way, I am not sure when 5.8.0 will be happening, but my best guess is probably something like 4-6 months from now. For the forthcoming 5.7.2 development release we are going to deploy something entirely new (binary releases for windows users), and presumably it will take us a while to respond to feedback from our windows users on those releases and any additional CBS and code issues they might find. So I wouldn't be surprised if we need at least a 5.7.3 development release (both source and binary) and probably a release candidate release for 5.8.0 before we finally go ahead with 5.8.0 final. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
