[crossfire] CVS -> SVN conversion

[Mark Wedel]

Nicolas Weeger (Laposte) wrote:
>> flex files that generate .c (loader.c) - not a big space user, yet at the
>> same time, pretty trivial for most people to generate (probably any system
>> that has gcc can pretty easily install flex if not already there).  The
>> flex files do not change very often.  The one question might be windows
>> (can they easily be regenerated there?).  Given these are small files, I'm
>> sort of mixed on these. The version of flex used to generate these files
>> really doesn't have any impact on performance - I don't think we've ever
>> had an issue where someone had a bad version of flex installed that caused
>> problems.
> 
> Windows users can generate loader.c with flex, already done that. Just need to 
> ensure the right flags are used (iirc case-insensitivity, for instance).

  Ok - so maybe leave out the flex generated files then.

> 
>> rebuilt lib files (Archetypes, images, etc):  These are the files I'm most
>> inclined to leave out of SVN.  The images tend to be quite big (slowing
>> down updates).  Plus, the updates are rather inconsistent - they are not
>> updated after every change is made to an arch, but rather when someone
>> remembers to or is some critical need.  Within SVN, we can set up lib/arch
>> to point to the actual arch tree, so an update of the server also gets
>> updated arches.  Plus, we already have all the tools in place to collect
>> them (the collect.pl script), so this doesn't add any additional software
>> dependencies.  If anything, this may actually help people use the updated
>> archs.
> 
> The only issue with that is that archs would now be part of the 
> whole "crossfire" module. Thus changing an arch will make a new server 
> version.
> Unless i'm wrong?

  If my understanding correct, the revision number will be unique for each of 
the different modules (arch, client, etc).

  Even if it isn't, that really isn't much different than if we have the 
collected ones - then when you collect the archetypes and check them in, that is 
updating the revision number, even though nothing in the server really changed.

  Right now, the archetypes file is not updated every time and arch file is 
updated, but in theory it could be.

  If anything, not having the collected files in the server tree would mean less 
server revisions.  Maybe 1 out of 10 (or 20) commits to the server is just a 
recollection of the archetypes, etc, and those wouldn't be needed anymore

> 
> BTW, while we're at messing with stuff, shouldn't "crossfire" be renamed 
> to "server"?

  There is really two issues here:

1) What is the module called within SVN.  In this case, I agree we should rename 
it server.
2) What is the executable that module makes is called.  This is really 
independent of the point above.  It should be renamed crossfire-server of 
cf-server of the like, but that is a change that should be made in the main head 
branch for the 2.0 release.

> 
>>   As a note, for any files that we automatically generate that are not
>> normally in SVN (if we so decide) yet are in the distributions we ship out,
>> I'd expect they would be in the release branch of the SVN repository for
>> that release (so you can go to the 1.10 branch and see what the archetypes
>> file had, or see what the makefile looked like, etc).  Although, maybe even
>> that is useless - could always just download the old releases.
> 
> As a remark, I'd say to automate stuff as much as possible in that case. That 
> is make a nice script building everything, collecting archetypes, generating 
> tarballs, all this stuff. Even if it only takes 15m to do by hand, that 
> becomes a pain fast :)
> (talking from Windows experience, where i should definitely automate things!)

  The makefiles will already recollect archetypes and build the flex files as 
needed.  So in a sense, the only extra work is to add those files in the 
repository.  But that part can certainly be in a script.