[Freeciv-Dev] Re: (PR#4712) future CVS versioning

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

John Wheeler wrote:
> [jdorje - Mon Jul 28 21:51:41 2003]:
> 
> 
>>See also PR#2479.
>>
>>It would be possible to have the cvs version string "automatically" 
>>updated, e.g. "cvs-yymmdd" or some such...but to do this right means 
>>moving the version information out of config.h and version.h and into 
>>version.c.  Right now every time the version changes everything has to 
>>be recompiled, which is bad.
>>
>>The version string has to go straight into CVS, not be generated by 
>>autoconf or configure.  We want the actual date of the CVS files, not 
>>the last date when ./configure was run.
>>
>>That said, the code portions would be pretty simple:
>>[code snipped]
>>and the only problem remaining is to determine how/when the version 
>>string is updated.
>>
>>We've looked into "automatic" updating of CVS, e.g., having a script
>>run  to update a file on every checking.  But this is a dangerous
>>hack - if not done correctly you can have deadlock when cvs tries to
>>commit within the commit.
>>
>>Another alternative is simply to have a cron job to run every so often 
>>to do the update checking.  This could be every day, every week, or 
>>every time a cvs checking is done.
> 
> 
> Would it work if the version string were put in its own text file, which
> would be updated in CVS after every commit and read in at runtime?  This
> should take care of needless recompiling (but, I wouldn't recommend it
> for stable versions).

This presents some technical problems with the script itself.  Reinier 
looked into it a while ago, and sent his results to RT somewhere.  From 
my understanding:

There is a commit callback mechanism that can be used.  However, running 
another commit from within this is dangerous since the CVS locks have 
already been acquired and then need to be acquired again - a possible 
deadlock condition.  (CVS locking is done on a per-directory basis.)

There's also the "check for commits" check that generates the 
freeciv-cvs mailing logs.  This is run every 10 minutes or so to check 
the output from the current commit callback script.  The version update 
commit could be done here.

In either case you have to be careful to avoid changing the version on 
non-HEAD branches (as you mention), and also to prevent recursive 
updating of the version (the commit for the version update should not 
trigger a version update).  Both are possible but potentially bug-prone.

That said, I don't know much about how any of this is done.  Reinier has 
set it all up in the past.  He'd be willing to do it again, I'm sure, 
but he has little free time.

>  Also, maybe should all the #defines be taken out
> of version.h, and use wrapper functions to access the values elsewhere
> in the program?  I would think doing this first would make it easier to
> change how the version is determined.

No doubt, and I would approve of a patch to do this.  Note that the 
version.h #defines are not generally used; the ones generated in 
config.h are used instead.  So removing the #defines from the header 
isn't really the goal, but rather removing their usage from .c files 
(other than version.c) (and replacing it with appropriate functions) 
would be.

jason