[crossfire] CVS -> SVN conversion

[Mark Wedel]

  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?