Re: gnats/gnats mkdb.sh

[Lars Henriksen]

On Wed, May 29, 2002 at 12:19:56PM -0700, Mel Hatzis wrote:
> I just noticed this 'fix' and feel compelled to argue against it.
> We *NEVER* use the gnats localhost mode...there's no need for it
> and IMO it ought to be deprecated. The network mode is perfectly
> fine for both local and remote uses.

I take your word for it and tend to agree.

> This fix effectively breaks mkdb in our environment where all
> databases are defined as remote (with host and port specified)
> and where the databases file is shared across a large number of
> workstations and servers (including the gnats server).

Then it breaks what was broken already. You can't have used mkdb
to create a database in your setup. 

I made the fix after reading the documentation (Keeping Track,
section 4.2) that explicitly excludes your setup:

  For a database that is located across a network, but which should be
  accessible from this host, the entry for the database should look like
  this:

     DATABASE NAME:SHORT DESCRIPTION OF DATABASE::HOSTNAME:PORT

  The first two fields are the same as for local databases, the third
  field is empty (notice the two adjacent `:' symbols, indicating an
  empty field), the fourth field is the hostname of the remote GNATS
  server, and the fifth field is the port number that the remote GNATS is
  running on.

Now, this may be all wrong (and no, I haven't checked the code), but
it does indicate that you may have a problem. I have been on the point
of asking you in another context whether entries like

  default:Bug database:/usr/local/com/gnatsdb:server.juniper.net:1529
  test:GNATS Test:/homes/hatzis/local/gnats/test:server.juniper.net:1529

might be a reason for the faulty behaviour of for example pr-edit.

> Rather than simply ignore all 'remote' databases, can I suggest
> capturing the host field (if it's defined) and checking it against
> the current host.

Hmm, this is easier said than done. The host field may contain a DNS
name different from any physical host name. In clusters this may be
further complicated by cluster aliases. But fine with me provided the
"combined" local/remote format really is supported by the code.

Lars Henriksen