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: "Reinier Post" <rp@xxxxxxxxxx>
Date: Thu, 22 May 2003 07:36:07 -0700
Reply-to: rt@xxxxxxxxxxxxxx

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.

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

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.

>       Raimar


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