As noted in anothe e-mail, SVN won the vote for the source code system for use on crossfire.
Next step is to actually switch over. Looking on sourceforge docs, I notice a few things: 1) They don't have a conversion utility, but rather directions (using cvs2svn) to make the change. 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). Given this, these are my thoughts: 1) A date for the switchover needs to be chosen. My personal inclination is sooner vs later, yet at the same time, want to give enough time in case people have work in progress that is almost ready to commit (so they don't have to resync/copy into SVN). The flip side of this is that if this is too far away, this could delay people starting working (don't want to be halfway done and then have to sync up again). I'm thinking maybe 9/18 (monday) as the date to switch over? Give people a week to commit their changes, etc. 2) Since CVS will remain on-line, I think the safest thing to do there is revoke everyones read/write access to CVS at said date, since there shouldn't be any reason for anyone to do commits. 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. All of these will remain in the Read-only cvs repository, so won't be lost. It just doesn't seem like there is any active development on these, so no reason to have them in SVN. 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? 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. I think that is it - anyone have any other issues/comments? _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire