[crossfire] CVS -> SVN conversion

[Alex Schultz]

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