gitstat-devel Mailing List for gitstat (Page 4)

For now, I am unable to post to lkml due to unknown reason.
I am using google apps for my @kldp.org mail address
but from some time ago, my post just get ignored
though I have subscribed to the list.

Sorry for not getting back earlier. I was out for the weekend.

Anyway, I sent the announcement to gi...@vg... which is
the list for git developers/users. I hope we could collect more interest.

/Shawn


2007/11/2, Paul Vriens <pau...@gm...>:
> Hi Shawn,
>
> Could you? I'm not a member (guess you have to be one to be able to post), nor
> do I wish to for now.
>
> Cheers,
>
> Paul.
>
> Soon-Son Kwon(Shawn) wrote:
> > well... the only way should be posting this news
> > to more places.
> >
> > linux kernel mailing list(lkml) and git mailing list
> > should be the candidate and also other projects
> > that uses git as their code mgmt system can
> > also be interested to this release.
> >
> >
> > 2007/11/2, Paul Vriens <pau...@gm...>:
> >> Paul Vriens wrote:
> >>> We are pleased to announce the release of gitstat 0.4.
> >>>
> >>> Gitstat is a GPL'd, web-based git statistics and monitoring system.
> >>>
> >>> This release is mainly a maintenance release with a lot of
> >>> restructuring. This release also puts some groundwork in for future
> >>> releases that will make the installation and configuration much more
> >>> friendly.
> >>>
> >>> New features:
> >>> - Automatic database updates on top of the base install
> >>> - Tag management on the admin page
> >>> - Multiple gitstat instances on one webserver
> >>> - More graphs can handle pages (back and forward in time)
> >>>
> >>> Needless to say that there is still a lot to do.
> >>>
> >>> You are welcome to try gitstat at http://tree.celinuxforum.org/gitstat
> >>>
> >>> For any suggestion, bug report, or patches, please visit
> >>> http://sourceforge.net/projects/gitstat
> >>>
> >>> Cheers,
> >>>
> >>> Paul.
> >>>
> >> Does anybody have some means to make more noise about this release? We need more
> >> input from users and probably more developers !
> >>
> >> Cheers,
> >>
> >> Paul.
> >>
> >> -------------------------------------------------------------------------
> >> This SF.net email is sponsored by: Splunk Inc.
> >> Still grepping through log files to find problems?  Stop.
> >> Now Search log events and configuration files using AJAX and a browser.
> >> Download your FREE copy of Splunk now >> http://get.splunk.com/
> >> _______________________________________________
> >> Gitstat-devel mailing list
> >> Git...@li...
> >> https://lists.sourceforge.net/lists/listinfo/gitstat-devel
> >>
> >
> >
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Gitstat-devel mailing list
> Git...@li...
> https://lists.sourceforge.net/lists/listinfo/gitstat-devel
>


-- 
http://kldp.org/~kss

Hi Shawn,

Could you? I'm not a member (guess you have to be one to be able to post), nor 
do I wish to for now.

Cheers,

Paul.

Soon-Son Kwon(Shawn) wrote:
> well... the only way should be posting this news
> to more places.
> 
> linux kernel mailing list(lkml) and git mailing list
> should be the candidate and also other projects
> that uses git as their code mgmt system can
> also be interested to this release.
> 
> 
> 2007/11/2, Paul Vriens <pau...@gm...>:
>> Paul Vriens wrote:
>>> We are pleased to announce the release of gitstat 0.4.
>>>
>>> Gitstat is a GPL'd, web-based git statistics and monitoring system.
>>>
>>> This release is mainly a maintenance release with a lot of
>>> restructuring. This release also puts some groundwork in for future
>>> releases that will make the installation and configuration much more
>>> friendly.
>>>
>>> New features:
>>> - Automatic database updates on top of the base install
>>> - Tag management on the admin page
>>> - Multiple gitstat instances on one webserver
>>> - More graphs can handle pages (back and forward in time)
>>>
>>> Needless to say that there is still a lot to do.
>>>
>>> You are welcome to try gitstat at http://tree.celinuxforum.org/gitstat
>>>
>>> For any suggestion, bug report, or patches, please visit
>>> http://sourceforge.net/projects/gitstat
>>>
>>> Cheers,
>>>
>>> Paul.
>>>
>> Does anybody have some means to make more noise about this release? We need more
>> input from users and probably more developers !
>>
>> Cheers,
>>
>> Paul.
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Gitstat-devel mailing list
>> Git...@li...
>> https://lists.sourceforge.net/lists/listinfo/gitstat-devel
>>
> 
> 

well... the only way should be posting this news
to more places.

linux kernel mailing list(lkml) and git mailing list
should be the candidate and also other projects
that uses git as their code mgmt system can
also be interested to this release.


2007/11/2, Paul Vriens <pau...@gm...>:
> Paul Vriens wrote:
> > We are pleased to announce the release of gitstat 0.4.
> >
> > Gitstat is a GPL'd, web-based git statistics and monitoring system.
> >
> > This release is mainly a maintenance release with a lot of
> > restructuring. This release also puts some groundwork in for future
> > releases that will make the installation and configuration much more
> > friendly.
> >
> > New features:
> > - Automatic database updates on top of the base install
> > - Tag management on the admin page
> > - Multiple gitstat instances on one webserver
> > - More graphs can handle pages (back and forward in time)
> >
> > Needless to say that there is still a lot to do.
> >
> > You are welcome to try gitstat at http://tree.celinuxforum.org/gitstat
> >
> > For any suggestion, bug report, or patches, please visit
> > http://sourceforge.net/projects/gitstat
> >
> > Cheers,
> >
> > Paul.
> >
> Does anybody have some means to make more noise about this release? We need more
> input from users and probably more developers !
>
> Cheers,
>
> Paul.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Gitstat-devel mailing list
> Git...@li...
> https://lists.sourceforge.net/lists/listinfo/gitstat-devel
>


-- 
http://kldp.org/~kss

Paul Vriens wrote:
> We are pleased to announce the release of gitstat 0.4.
> 
> Gitstat is a GPL’d, web-based git statistics and monitoring system.
> 
> This release is mainly a maintenance release with a lot of 
> restructuring. This release also puts some groundwork in for future 
> releases that will make the installation and configuration much more 
> friendly.
> 
> New features:
> - Automatic database updates on top of the base install
> - Tag management on the admin page
> - Multiple gitstat instances on one webserver
> - More graphs can handle pages (back and forward in time)
> 
> Needless to say that there is still a lot to do.
> 
> You are welcome to try gitstat at http://tree.celinuxforum.org/gitstat
> 
> For any suggestion, bug report, or patches, please visit 
> http://sourceforge.net/projects/gitstat
> 
> Cheers,
> 
> Paul.
> 
Does anybody have some means to make more noise about this release? We need more 
input from users and probably more developers !

Cheers,

Paul.

We are pleased to announce the release of gitstat 0.4.

Gitstat is a GPL’d, web-based git statistics and monitoring system.

This release is mainly a maintenance release with a lot of restructuring. This 
release also puts some groundwork in for future releases that will make the 
installation and configuration much more friendly.

New features:
- Automatic database updates on top of the base install
- Tag management on the admin page
- Multiple gitstat instances on one webserver
- More graphs can handle pages (back and forward in time)

Needless to say that there is still a lot to do.

You are welcome to try gitstat at http://tree.celinuxforum.org/gitstat

For any suggestion, bug report, or patches, please visit 
http://sourceforge.net/projects/gitstat

Cheers,

Paul.

Hi,

While playing with the new tag management I've discovered a bug with our 
implementation (See BUG 1807418) or a limitation in URL size or Apache or PHP.

What basically happens it that we pass to much data (URL length?) to our 
piechart.php. The current link for v2.6.22 of the kernel is already 7994 
characters long. For the v2.6.23 kernel it will be even longer as there were 
more participants (authors).

I've thought of several solution:

- do all the calculations before we go to piechart.php. We currently do the 
calculation and limiting in piechart.php. If we limit we assign 'etc' with the 
rest. We could do that of course before calling and sent only 21 values (20 real 
ones and the "etc").

- use the database as in intermediate step for passing the data:

In for example index.php or chart.php:
1. Generate the needed data strings and store it in a table
2. Retrieve the row where the data is stored
3. Pass the row number (unique id) to the graph generating script
In the graph generating script like piechart.php:
4. Retrieve the data identified by the given row
5. Draw the d*mn thing.

My preference is number 2 as it will also solve the huge URL's we are currently 
having. The downfall of number 2 is that we store stuff in the database and we 
have to remove it every now and then. We can't remove it straight away as that 
would mean the user can't click on the picture anymore. (Or we change the URL 
for the picture to point to index.php/chart.php with enough options to generate 
the chart again but that will mean performance).

I already had a working prototype of number 2 a few weeks ago. I didn't find a 
satisfying way to delete that data in the database though. I'm thinking of doing 
this via a batch job that deletes data older than 1 or 2 days.

This time I really like some input :-)

Cheers,

Paul.

Hi,

On my test/development box I have two 'instances' of gitstat. One that covers
the kernel and one that covers Wine.

We were using $_SESSION['apid'] to hold the email address of the users that's 
logged in. Needless to say that when I logged in to 'Kernel', 'Wine' also 
thought that I was logged in and looking at the email-address it shows the 
'Kernel' one. Confusion altogether.

I've fixed this by introducing:

$_SESSION[$GSTAT[GIT_PROJECT_NAME]] to hold the email address of the logged in 
user. I of course rely here on the fact that project names will most of the time 
be different.

I had to fix another problem after this. When I login to both everything is fine 
but when I logout of one I was also 'logged out' of the other because the 
session was destroyed.

I've fixed that by introducing:

$_SESSION['sessioncount'] that's incremented on login() and decremented on 
logout(). The session is only destroyed when $_SESSION['sessioncount'] reaches 0.

It's not perfect but it works for me.

Cheers,

Paul.

Of course we need to get more attention
by making more noises(?) to git or other
open source projects which use git for
their source code management tool. :-)

Every time I read your message, I am very
sorry that I and Jeongseong cannot spare
enough time these days.

We appreciate your effort very much and
I am sure we will be able to recruit more members
considering the uniqueness of our effort.

2007/10/2, Paul Vriens <pau...@gm...>:
> Hi,
>
> I've just committed a first change to index.php that makes use of the new
> visible flag.
>
> Currently you can change the visibility of a flag only through the admin page
> but I guess it has to be user specific at some point in time.
>
> Visibility means that instead of relying on some hardcoded check for the length
> of a version/tag name we now rely on this visible field. This makes sure that we
> are not kernel release centric anymore. The downside is that you have to make
> all the rc-version of the kernel in-visible to have the same output as before.
>
> The tag management can change of course to include some common queries instead
> of checking each single tag.
>
> Next patches will make sure we get rid of the "< 8" checks in the code and
> instead will rely on the visible flag.
>
> Comments/remarks/suggestions are welcome as always (but I think only 3 people
> read this list :-(, including me )
>
> Cheers,
>
> Paul.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Gitstat-devel mailing list
> Git...@li...
> https://lists.sourceforge.net/lists/listinfo/gitstat-devel
>


-- 
http://kldp.org/~kss

Hi,

I've just committed a first change to index.php that makes use of the new 
visible flag.

Currently you can change the visibility of a flag only through the admin page 
but I guess it has to be user specific at some point in time.

Visibility means that instead of relying on some hardcoded check for the length 
of a version/tag name we now rely on this visible field. This makes sure that we 
are not kernel release centric anymore. The downside is that you have to make 
all the rc-version of the kernel in-visible to have the same output as before.

The tag management can change of course to include some common queries instead 
of checking each single tag.

Next patches will make sure we get rid of the "< 8" checks in the code and 
instead will rely on the visible flag.

Comments/remarks/suggestions are welcome as always (but I think only 3 people 
read this list :-(, including me )

Cheers,

Paul.

Hi,

I want to change header.php so that the rest of the files have to include 
lib.php themselves instead of relying on the include via header.php. The intent 
of header.php is markup and should not be used otherwise I guess.

I guess just doing a: include_once "include/lib.php" in header.php would have 
that effect. We need the include_once as we check if the admin user is logged in.

Objections?

Cheers,

Paul.

Hi,

We currently have something like:

<div id=header>
<div class=content>
	<div id=articles>
		<div id=left>
		<div id=right>
	<div id=footer>

(so footer is part of content0

Wouldn't it make more sense to have:

<div id=header>
<div class=content>
	<div id=articles>
		<div id=left>
		<div id=right>
<div id=footer>

There is a comment in footer.php (<!--end of div content-->) but no associated 
/div with it.

Cheers,

Paul.

Hi

I've added the 'infrastructure' to update the schema of the db. This makes it 
possible to create the initial database (not used yet) and also to update to the 
latest schema. The updatedb() function takes care of all intermediate steps.

This means that all additions to the schema should go via the newly created 
libdb.php and not via single sql-scripts. For now we should add the complete 
schema also to install/sql/gitstat.sql but this file will be removed in the 
(nearby) future to be replaced by a installation 'infrastructure'.

(reminder to self to add gitstat_settings to gitstat.sql)

Next thing I will do is add a field to the v_tag table to indicate whether a tag 
should be visible or not in the graph creation. This will be a major step away 
from the current kernel-centric gitstat.

Once the installation infrastructure is there I think we should launch a new 
version, 0.4.

As always, comments/remarks/suggestions are welcome.

Cheers,

PAul.

I think it is good to have more flexibility
so that people can configure gitstat for more
than two projects!


2007/9/29, Paul Vriens <pau...@gm...>:
> Hi,
>
> This 'apid' (which is a fixed name) is bothering me more and more. For testing
> purposes I have 2 gitstat instances running on my box (2.6 Kernel and Wine).
> When I login to one the other also shows 'Logged in' which is of course not
> correct but is due to this single variable.
>
> I'm think of embedding the project name into this variable. Or maybe even the
> database name.
>
> Any other/better ideas?
>
> Cheers,
>
> Paul.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Gitstat-devel mailing list
> Git...@li...
> https://lists.sourceforge.net/lists/listinfo/gitstat-devel
>


-- 
http://kldp.org/~kss

Hi,

This 'apid' (which is a fixed name) is bothering me more and more. For testing 
purposes I have 2 gitstat instances running on my box (2.6 Kernel and Wine). 
When I login to one the other also shows 'Logged in' which is of course not 
correct but is due to this single variable.

I'm think of embedding the project name into this variable. Or maybe even the 
database name.

Any other/better ideas?

Cheers,

Paul.

Hi,

Just wanted to let people know that I've created a new directory "include" that 
is now holding lib.php. We've lost the history for lib.php but I don't think 
that's a great loss yet.

This new "include" directory will also contain libdb.php which is solely for 
database stuff (which also means moving dbconnect from lib.php to libdb.php).

I'm also thinking of move the graph generating stuff to there (linegraph, 
bargraph and piegraph).

Cheers,

Paul.

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.

I saw some commits in header.php
It was modified for admin menu.
So, admin link had been added and cleaned up some codes.

But there is a trifle problem.
For getting respected design(?), it should not have any whitespace between
each link( e.g <a href=....></a>'here'<a href>).
If there are any whitespace, link would get unexpecting padding.
I modified some code for this reason.

Thanks,

Hi,

Just wanting to let you know that I did a huge cleanup of chart.php (I must say 
a bit more to my liking now).

- removed some whitespace (empty lines with only tabs replaced by empty lines).
- more consistent indentation
- more consistent use of "while(){" and "if(){", sometimes the bracket were on 
the next line

I did find one very small bug where a </a> and </center> where in the wrong order.

Now it's time to do some real hacking on chart.php as there are some things that 
needs changing because of bugs.

Cheers,

Paul.

P.S I will do the same cleanup to other files once I start really working on them.

Soon-Son Kwon(Shawn) wrote:
> Please go ahead anything first without asking... :-)
> 
> Jeongseong is currently out of office and I cannot work on it
> so you do not need to ask to us. As long as you leave the
> log message well, we will be able to catch up quickly.
> 
> 
> 2007/9/11, Paul Vriens <pau...@gm...>:
>> Hi,
>>
>> We do a lot of duplicate things in index.php and chart.php. Would it be
>> worthwhile to move some common code to a new file (chartfunc.php) or even
>> include it in lib.php?
>>
>> Cheers,
>>
>> Paul.
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Gitstat-devel mailing list
>> Git...@li...
>> https://lists.sourceforge.net/lists/listinfo/gitstat-devel
>>
> 
> 
That explains why I don't get any reactions on my emails :-).

Cheers,

Paul.

Please go ahead anything first without asking... :-)

Jeongseong is currently out of office and I cannot work on it
so you do not need to ask to us. As long as you leave the
log message well, we will be able to catch up quickly.


2007/9/11, Paul Vriens <pau...@gm...>:
> Hi,
>
> We do a lot of duplicate things in index.php and chart.php. Would it be
> worthwhile to move some common code to a new file (chartfunc.php) or even
> include it in lib.php?
>
> Cheers,
>
> Paul.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Gitstat-devel mailing list
> Git...@li...
> https://lists.sourceforge.net/lists/listinfo/gitstat-devel
>


-- 
http://kldp.org/~kss

Hi,

We do a lot of duplicate things in index.php and chart.php. Would it be 
worthwhile to move some common code to a new file (chartfunc.php) or even 
include it in lib.php?

Cheers,

Paul.

Paul Vriens wrote:
> Paul Vriens wrote:
>> Hi,
>>
>> I just committed a change (temp. fix) to chart.php. With the change 
>> from 'committer' to 'author' the amount of data passed to horizbar.php 
>> changed.
>>
>> If you (without the patch) go to:
>>
>> http://tree.celinuxforum.org/gitstat/chart.php?chart_parameter1=3&chart_parameter_ver=v2.6.22&submit=1&chart_parameter2_year=2007&chart_parameter2_month=0&submit=1 
>>
>>
>> you'll see what I mean, no graph at all.
>>
>> There is currently a hardcoded limit of 10 entries in horizbar.php but 
>> that wasn't the issue. The real issue is that we pushed to much data 
>> to horizbar.php.
>>
>> Any idea of the limits? Maybe I should be starting harder to think of 
>> not passing the data via the URL but doing it via the database as I've 
>> tried to do a few days ago (and which was working btw).
>>
>> Cheers,
>>
>> Paul.
>>
> Hi,
> 
> It looks the problem is a little different as I thought. If you look at 
> the mentioned page you see one strange entry for the Group:
> 
> Fernando Luis [** ISO-8859-1 charset **] VázquezCao
> 
> I'll have a check later on. For now the patch doesn't do any harm though.
> 
> Cheers,
> 
> Paul.
> 
Hi,

It seems that these commits are already 'wrong' in git:

commit 45ae5e968ea01d8326833ca2863cec5183ce1930
Author: Fernando Luis [** ISO-8859-1 charset **] V<E1>zquezCao <fernando@oss.ntt
Date:   Wed May 2 19:27:18 2007 +0200

     [PATCH] i386: __send_IPI_dest_field - i386

So we should either filter them out on insertion to the DB or when retrieving.

What is the best approach?

Cheers,

Paul.

Paul Vriens wrote:
> Hi,
> 
> I just committed a change (temp. fix) to chart.php. With the change from 
> 'committer' to 'author' the amount of data passed to horizbar.php changed.
> 
> If you (without the patch) go to:
> 
> http://tree.celinuxforum.org/gitstat/chart.php?chart_parameter1=3&chart_parameter_ver=v2.6.22&submit=1&chart_parameter2_year=2007&chart_parameter2_month=0&submit=1 
> 
> 
> you'll see what I mean, no graph at all.
> 
> There is currently a hardcoded limit of 10 entries in horizbar.php but 
> that wasn't the issue. The real issue is that we pushed to much data to 
> horizbar.php.
> 
> Any idea of the limits? Maybe I should be starting harder to think of 
> not passing the data via the URL but doing it via the database as I've 
> tried to do a few days ago (and which was working btw).
> 
> Cheers,
> 
> Paul.
> 
Hi,

It looks the problem is a little different as I thought. If you look at the 
mentioned page you see one strange entry for the Group:

Fernando Luis [** ISO-8859-1 charset **] VázquezCao

I'll have a check later on. For now the patch doesn't do any harm though.

Cheers,

Paul.

Hi,

I just committed a change (temp. fix) to chart.php. With the change from 
'committer' to 'author' the amount of data passed to horizbar.php changed.

If you (without the patch) go to:

http://tree.celinuxforum.org/gitstat/chart.php?chart_parameter1=3&chart_parameter_ver=v2.6.22&submit=1&chart_parameter2_year=2007&chart_parameter2_month=0&submit=1

you'll see what I mean, no graph at all.

There is currently a hardcoded limit of 10 entries in horizbar.php but that 
wasn't the issue. The real issue is that we pushed to much data to horizbar.php.

Any idea of the limits? Maybe I should be starting harder to think of not 
passing the data via the URL but doing it via the database as I've tried to do a 
few days ago (and which was working btw).

Cheers,

Paul.

Good suggestion.
I agree that we need to move some scripts.
e.g. graph related scripts.

but I don't know what means 'include'?
I think that It looks good, we could see most of files when we extract
.tgz file.

Thanks,


On 9/9/07, Paul Vriens <pau...@gm...> wrote:
> Hi,
>
> Currently most of our php scripts are in the root of the project. What about
> introducing some directories where we move stuff, for example:
>
> include - for most of our php-scripts
> gstat_graph - for the graph related scripts (like piegraph.php)
>
> I again welcome ideas/remarks/suggestions.
>
> Cheers,
>
> Paul.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Gitstat-devel mailing list
> Git...@li...
> https://lists.sourceforge.net/lists/listinfo/gitstat-devel
>