Complete.Org: Mailing Lists: Archives: freeciv-dev: May 2003:
[Freeciv-Dev] Re: commit numbering on the CVS tree (was: (PR#4131) 'make

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: jdorje@xxxxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: commit numbering on the CVS tree (was: (PR#4131) 'make dist' for the daily snapshot)
From: "Raimar Falke" <rf13@xxxxxxxxxxxxxxxxx>
Date: Fri, 23 May 2003 02:26:28 -0700
Reply-to: rt@xxxxxxxxxxxxxx

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


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"


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

[Prev in Thread] Current Thread [Next in Thread]