On Tue, Mar 20, 2007 at 07:47:12AM +1200, Martin Langhoff wrote: > On 3/20/07, Frank Lichtenheld <frank@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> www: http://www.djpig.de/ - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html