Hi,
As you can probably see from the CVS statistics I didn't have much time to play
with gitstat the last weeks. That certainly won't change in the nearby future
unfortunately.
My last patches were mostly about cleanups. I've been busy for the last week to
create an installation.php. The idea is that this (together with some library
stuff) is going to replace the manual installation of the database.
This is what installation.php currently does:
1. Asks for the servername/username/password and verifies this.
2. Asks for new databasename and checks if it exists (it won't work currently
with an existing one).
3. Write the above parameters to a new config file 'dbconfig.php' in a new
config directory.
4. Creates the database.
5. Fills the database with the latest schema.
6. Adds the first admin user.
The idea is that this installation.php will be presented to the user as long as
there is no database and dbconfig.php but also if all is correct but the
installation.php file still exists. The administrator/installer of gitstat
should remove installation.php on completion of the database creation.
The next steps an administrator/installer should peform:
7. Log in as an admin user.
8. Configure the rest of gitstat (the stuff that's currently in the config.php).
To accomplish the filling of the database I've started working on a new
libdb.php that should cover all db related functions in the future. It currently
install the base schema (the one when gitstat started V0.1) and updates the db
with all schema changes:
- the one that adds 'filename' for single file tracking (V0.1 -> V0.2)
- a new one that creates a table 'gitstat_settings' that for now only holds the
version of the schema (being '2' after this one).
The update routine of the schema will of course check the current state against
the new one, hence the addition of the gitstat_settings table. The only
parameter in there (for now) is 'dbver' (or something like that).
The idea is that we will will only have a limited amount of configuration
parameters in a file. Most of them should be in the table giststat_settings.
This will be done by a new 'module' in admin.php (in the future).
The first change to the schema will be to add some information about the
visibility of tags. This visibility flag will tell if a tag needs to be
considered in our graph creating routines. This is needed to overcome some
hardcoded settings that only are true for the linux kernel.
I also need to find the best way to make sure we don't have the (more-or-less)
same configuration steps for the perl-side of things.
So bottom line is that I'm still working on gitstat but in a slow pace. I also
think we have to wait for the above changes to come out with a new release. My
first estimate is that this will take a week or 2. Expect the first new patches
in a few days.
If you need more information don't hesitate to contact me.
Any suggestion/remark is welcome. Please also respond if you are currently
working on something.
Cheers,
Paul.
|
