Re: [PATCH 4/5] cvsserver: Make the database backend configurable

[Frank Lichtenheld <frank@lichtenheld.de>]

On Tue, Mar 20, 2007 at 07:47:12AM +1200, Martin Langhoff wrote:
> On 3/20/07, Frank Lichtenheld <frank@lichtenheld.de> wrote:
> >Make all the different parts of the database backend connection
> >configurable. This adds the following string configuration variables:
> 
> Nice. I guess the hard part of this is going to be creating DB schemas
> that are reasonably portable. The SQL we use is as vanilla as it gets
> ;-)

I've now actually made a quick test to see how we do when using other
backends (with PostgreSQL 8.2, will also do one with MySQL later).

Some problems that I saw:

 - It would probably cool to be able to tell git-cvsserver that it
   should use only one database for all modules (i.e. git branches)
   This way one doesn't need to give the users database creation
   privileges. Of course pre-creating all databases possibly ever needed
   is possible but somewhat cumbersome.
 
 - DBI->tables seems to be a portability problem. e.g. with SQLite
   it returns "head", "commitmsgs", etc; with PostgreSQL it returns
   public.head, public.commitmsgs, etc. The output of MySQL might
   be different, too.

> >Both dbname and dbuser support dynamic variable substitution where
> >the available variables are:
> >%m -- the CVS 'module' (i.e. GIT 'head') worked on
> >%a -- CVS access method used (i.e. 'ext' or 'pserver')
> >%u -- User name of the user invoking git-cvsserver
> >%G -- .git directory name
> >%g -- .git directory name, mangled to be used in a filename,
> >      currently this substitutes all chars except for [\w.-]
> >      with '_'
> 
> It's missing from the POD though ;-)

You mean the asciidoc, right?

And yeah, I know. Writing English documentation is not actually one of my
preferred occupations :/ Will do it, though.

[...]
> with those 2 in place, we'd have a means of applying a "vampire tap"
> to an existing cvs server and take over without anyone noticing. But
> tehy are both hard, hard hard.

Indeed.

Gruesse,
-- 
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/