[Freeciv-Dev] Re: commit numbering on the CVS tree (was: (PR#4131) 'make dist' for the daily snapshot)

["Raimar Falke" <rf13@xxxxxxxxxxxxxxxxx>]

On Thu, May 15, 2003 at 11:39:10AM -0700, Reinier Post wrote:
> On Mon, May 05, 2003 at 07:15:15AM -0700, Jason Short wrote:
> 
> [...]
> 
> > One problem is that the tarball does not have a constant name.  This may 
> > make it difficult to just copy the tarball over and use it.  In fact, 
> > when you untar the tarball it will give you a directory 
> > freeciv-<version>, which is not exactly what we want (but might be 
> > okay).  If the CVS had consistent versioning (as discussed on RT), this 
> > would be solved.
> 
> [...]
> 
> I'm sorry, I got stuck on this.  My idea was to let every checkin
> generate a version number automatically by making it perform a checkin
> itself.  I've been running this for a while, using the attached script,
> but it isn't completely robust, there are possible locking problems,
> which can largely be avoided by making sure the version number file
> is in a separate directory that never gets used for anything else.
> Perhaps the CVSROOT/modules file can be used to solve the problem that
> the version file must be part of the module that is normally checked out,
> but must not be explicitly committable by the user.
> 
> The comment in the script makes clear that I'm not sure on whether to
> run it from CVS/commitinfo (which is called at the start of the commit)
> or CVS/loginfo (which is called at the end).  To work perfectly the
> commit should lock out all other operations (including reads) which I
> don't think is something that CVS guarantees by itself.  Perhaps a good
> workaround is to call the script twice: in commitinfo, to write 
> a version number indicating that commit number x has been started,
> and in loginfo, writing a version number to indicate that the commit
> has been finished.
> 
> In short, this just took longer than I thought and I can't promise
> to finish it any time soon.  So I'm just posting what I have so far.

I discussed this problem with some people here and they came up with
the following solution: there is a wrapper script around "cvs
server". The wrapper is started by inetd and starts "cvs server". The
wrapper has to lock itself against:
 - other commiting invocations of itself (easy)
 - other local commits (harder, but may be easy if we just forbid
 local commits)

If we want a consistent view of the clients the wrapper also has to
lock itself with updates calls of the pserver (I think this is easy).

So the wrapper script will look like this:
 1) lock
 2) call the real "cvs server"
 2.1) in loginfo or commitinfo the message is saved
 3) commit the special version file with the message saved under 2.1
 4) unlock

Looks like it can be done. What do I miss?

I was also informed that the protocol used between client and server
_is_ specified. "info cvsclient" or just look at
<http://www-es.fernuni-hagen.de/cgi-bin/info2html?(cvsclient)Protocol>

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "- Amiga Y2K fixes (a bit late, wouldn't you say?)"
    -- Linus Torvalds about linux 2.4.0 at 4 Jan 2001