Mark Wedel wrote: > 2) The CVS respository does not appear it will go away, so after the > conversion, > both SVN and CVS access will be available. However, only updates should be > done > to SVN, so CVS will go out of date (but is still probably useful as a > reference > for older releases). IMHO it's not worth doing, but in theory it would be possible to use a tool like tailor to incrementally update the CVS copy every so often. I don't think it would be awfully useful, however just pointing this out in case someone does think something like that would be useful.
> <snip> > 3) Since we can decide what files to import or not import, it may be a > reasonable time to clean up some of the directories in the CVS root tree > right > now (eg, not move them to SVN), particularly: > > alternate_images: These have been merged into the main arch tree long ago. > cfclient_sdl: I don't think has been updated in many years - I have a feeling > daimonin probably has a more up to date version that should be examined if > we're > serious about this. > client/gnome: hasn't been supported in a long time > iso_arch: Like cfclient_sdl above - really not used since daimonin. > maps: Been replaced by maps-bigworld. > <snip> > This seems like a good idea to me. Also, perhaps we shouldn't move CFJavaEditor, and instead use 'svn:externals' (See http://svnbook.red-bean.com/en/1.0/ch07s03.html) to link to Gridarta's copy of CFJavaEditor in their SVN repository. To do so would be something along the lines of this inside of a new empty CFJavaEditor svn repository: svn propset svn:externals 'https://svn.sourceforge.net/svnroot/gridarta/trunk/crossfire' . Which would effectively redirect svn clients to that url to download it if they would try something like a "svn checkout https://svn.sourceforge.net/svnroot/crossfire/CFJavaeditor";. This makes sense to me because active CFJavaEditor development is happening in the Gridarta project, and if the old history is needed for historical reasons we have the cvs repository of it around. > 4) I don't believe the SVN by default provides support for the $Id$ string > version control at the top of files. I thik there may be modules that > support > it, but sourceforge is very particular in what modules they support (short > list > being ones that provide e-mail notification, and another that checkes file > names > for reasonable compliance). There may be client side scripts that could be > used, but then that seems a little more problematic (some developers forget > to > use/install them, so their commits are not updated, etc). Does it just make > sense to pull the $Id strings out of the files then? > Well, the $Id strings have never seemed terribly useful to me (it was often more convenient for me to just check the timestamp of the build and/or source directory if I wanted to know when in CVS it was built from), however if anyone has any use for them, probably wouldn't be difficult to make a script to generate a .h file containing macros of that data, and put that in as part of the build system. > 5) I might try uploading a converted repository before the 9/18 date to find > any > issues - in this case, it could be used for testing, but would be blown away > on > 9/18 when actual conversion is done. > Would be be nice to have a testing one uploaded a bit early. For one, this would give people a chance to fiddle around with how various svn things (branches, svk local branches, bzr-svn local branches, etc.) would work on on the crossfire tree ahead of time. Alex Schultz _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
