[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 22, 2003 at 07:36:07AM -0700, Reinier Post wrote:
> On Thu, May 22, 2003 at 05:39:35AM -0700, Raimar Falke wrote:
> 
> > 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".
> 
> Bear in mind that inetd is only used for pserver access,
> i.e. public read-only access.  All commits use ssh to a local account.

Uhhh. Yes you are right.

> > 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)
> 
> Nice, except that all commits *are* local.
> However, the cvs command itself can be replaced with a wrapper.
> The reason I didn't want to do that is that the wrapper might
> accidentically get destroyed when cvs is updated.  Not a major problem.
> 
> > 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).
> 
> It's easy (my script does this) except that you must avoid recursion
> if cvs ci is used for locking.  But that isn't necessary in this
> approach.  This is the problem I was referring to.
> 
> > 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
> 
> Here you must avoid recursion.  A cvs ci operates per directory,
> and locks that directory (by placing a lockfile in it).
> It already has that directory locked when commitinfo is run, so
> commitinfo must not ever cvs ci on the same directory.

Step 3 is done after the "main" commit finished. No recursion.

> You also have to somehow make sure the present cvs action doesn't
> already do something like trying to commit the special version file itself.
> (See the script I attached.)
> 
> >  4) unlock
> > 
> > Looks like it can be done. What do I miss?
> 
> Looks OK.
> 
> > 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>
> 
> That is very interesting to know.  By making the wrapper actually
> edit the byte stream, all issues with other solutions disappear.
> Instead you become dependent on clients and new server versions
> not breaking the documented protocol.

Yes.

Another point which all solutions have: it is unknown how the client
will cope with the fact that the server changed the special-file
without the client knowing. This is especially true if we change the
network stream and so the client gets information about the new
revision of the special-file from the server without requesting the
commit of this file.

So the least that has to be done is that the commiter has to "cvs up"
afterwards.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "The two rules for success in life are:
  1) Never tell them everything you know."