[crossfire] CVS -> SVN conversion

[Mark Wedel]

Alex Schultz wrote:
> 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.

  Not sure about tailor, but IIRC, one of the issues with most of these 
conversion tools is they do not deal with branches very well (probably because 
the branch methods vary wildly - in the case of SVN, branches are basically new 
copies of the repository).

  I forgot to mention in my previous e-mail, one of the first things I'll do 
once we move to SVN is to make a branch for the 1.x releases (with the main/head 
branch being for 2.x).

> 
>> <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.
> 

  could do that. But then I wonder if that makes sense, or if whatever docs 
should just be updated to point to the gridarta repository.

  One reason here is developer permissions - if it is in the crossfire SVN root, 
people may expect that since they have crossfire SVN write permissions, they 
should be able to make updates to it - however, if it is a link, they won't.

  All that said, if CFJavaEditor has been superseded by gridarta, then it 
doesn't make sense to have a copy in the crossfire tree - so the question more 
becomes should a redirection be done, or just nothing at all?

>> 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.

  The client had been modified at one point to provide that information, just to 
be more helpful in bug reports.

  That said, I agree that the header in each file probably isn't necessary.  It 
might be nice to include the svn commit number in a header file, so that could 
be displayed, eg, the client could say something like:

  Crossfire Client 1.10 build 8963

  Such that if a user reports a bug, we can easily check that global revision 
number and see if the bug may have been fixed, etc.