gitstat-devel — for developers

Re: [Gitstat-devel] New code that uses HTTP_REFERER doesn't work for me

[<jun...@gm...>]

I used domain name instead of 'chart.php' at tree.celinuxforum.org.
I made some plan to make variable for domain name in config.php and to
check that variable.
and I tested on MSIE and firefox 2.0 and 1.0.
but, so it seems to be some problem. As has been mentioned it cannot be trusted.

I have read your e-mail about a solution with DB,
but, there is some downside.
if 'chart.php' takes long time or server have  traffic, some user
could leave chart page.
in case of that, chart-table had been created and and couldn't be removed .
but I thought that it works fine in many case .

If you could make patch for this ,it could be better solution.
could u make it for gitstat user?
Thanks,

On 9/4/07, Paul Vriens <pau...@gm...> wrote:
> Hi,
>
> When I now go to the main page (index.php) I don't get to see any of the charts.
> My apache error_log show index.php as being the referer and not chart.php.
>
> I have to check for both index.php and chart.php to get everything working.
>
> What version of apache/php are you running?
>
> And btw on the page http://nl3.php.net/reserved.variables it's mentioned that:
>
> ==
> 'HTTP_REFERER'
>     The address of the page (if any) which referred the user agent to the
> current page. This is set by the user agent. Not all user agents will set this,
> and some provide the ability to modify HTTP_REFERER as a feature. In short, it
> cannot really be trusted.
> ==
>
> 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
>

Re: [Gitstat-devel] [feature request 1783070] A list of things that are still Kernel centric

[Paul V. <pau...@gm...>]

이정승 wrote:
> Good job,
> It seems to be nice solution.!
> 
> I didn't analyze this patch yet.
> but, I'll check this patch deeply and If it works well,
> I'll include it new release.
> Thanks for your contribution.
> 
> 
Just had a quick look at my patches to gitstat and the linux kernel. There is
one tag in there with no commit (as mentioned by Linus):

[paul@penguin linux-2.6.git]$ git-cat-file tag
5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c
object c39ae07f393806ccf406ef966e9a15afc43cc36a
type tree
tag v2.6.11-tree

This is the 2.6.11 tree object.

NOTE! There's no commit for this, since it happened before I started with git.
Eventually we'll import some sort of history, and that should tie this tree
object up to a real commit. In the meantime, this acts as an anchor point for
doing diffs etc under git.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBCeV/eF3YsRnbiHLsRAl+SAKCVp8lVXwpUhMEvy8N5jVBd16UCmACeOtP6
KLMHist5yj0sw1E4hDTyQa0=
=/bIK
-----END PGP SIGNATURE-----

Doing a git-cat-file commit c39ae07f393806ccf406ef966e9a15afc43cc36a gives
(obviously):

[paul@penguin linux-2.6.git]$ git-cat-file commit
c39ae07f393806ccf406ef966e9a15afc43cc36a
fatal: git-cat-file c39ae07f393806ccf406ef966e9a15afc43cc36a: bad file

Several of the kernel tags (from v2.6.11-tree upto v2.6.13-rc3) have no tagger.

The new patch (attached) skips the not so valid tags (like v2.6.11-tree). The
screenshot 'before' shows the current state and 'after' with my patches.

Cheers,

Paul.

[Gitstat-devel] New code that uses HTTP_REFERER doesn't work for me

[Paul V. <pau...@gm...>]

Hi,

When I now go to the main page (index.php) I don't get to see any of the charts. 
My apache error_log show index.php as being the referer and not chart.php.

I have to check for both index.php and chart.php to get everything working.

What version of apache/php are you running?

And btw on the page http://nl3.php.net/reserved.variables it's mentioned that:

==
'HTTP_REFERER'
     The address of the page (if any) which referred the user agent to the 
current page. This is set by the user agent. Not all user agents will set this, 
and some provide the ability to modify HTTP_REFERER as a feature. In short, it 
cannot really be trusted.
==

Cheers,

Paul.

Re: [Gitstat-devel] [feature request 1783070] A list of things that are still Kernel centric

[Paul V. <pau...@gm...>]

??? wrote:
> Hi,
> I applied your taglist patch, but it didn't work well.
> I received this mesage.
> 
>> $ ./gitstat.pl HEAD
>> fatal: git-cat-file c39ae07f393806ccf406ef966e9a15afc43cc36a: bad file
>> Can't use an undefined value as an ARRAY reference at ./gitstat.pl line 123.
> 
> First of all, I dropped all gitstat table and git tree and I patched
> parser.pl and  lib.pl.
> and then run gitstat.pl.
> Did you tested on other step? Is there any solution?
> Thanks.
> 
> -------------------------------------------------------------------------
> 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
> 
Did you use my second patch? The first one had indeed that failure.

I'll attach it again.

Cheers,

Paul

Re: [Gitstat-devel] [feature request 1783070] A list of things that are still Kernel centric

[<jun...@gm...>]

Hi,
I applied your taglist patch, but it didn't work well.
I received this mesage.

>$ ./gitstat.pl HEAD
>fatal: git-cat-file c39ae07f393806ccf406ef966e9a15afc43cc36a: bad file
>Can't use an undefined value as an ARRAY reference at ./gitstat.pl line 123.

First of all, I dropped all gitstat table and git tree and I patched
parser.pl and  lib.pl.
and then run gitstat.pl.
Did you tested on other step? Is there any solution?
Thanks.

Re: [Gitstat-devel] [bug 1785778] sql query to get the maximum commits

[<jun...@gm...>]

Hi,
gitstat has not only some bugs but also many trivial bugs, you know.
Actually, we need helping hand like you.:)
you gave me good query string, so I could modify easily,
I'll handle this issue like your comment.

Thanks,

On 9/3/07, Paul Vriens <pau...@gm...> wrote:
> Hi,
>
> (This relates to bug 1785578 'ybase is set fixed for "number of changesets" graph')
>
> I've figured out the sql statement to get the maximum number of commits in the
> changeset:
>
> mysql> select max(maxcommits) from (select
> count(DATE_FORMAT(FROM_UNIXTIME(commitdate),'%Y%m%d')) as maxcommits
> from ChangeLog group by
> DATE_FORMAT(FROM_UNIXTIME(commitdate),'%Y%m%d')) as t1;
> +-----------------+
> | max(maxcommits) |
> +-----------------+
> |             733 |
> +-----------------+
> 1 row in set (0.22 sec)
>
> You see even the '700' that is currently set for the linux kernel is not enough ;-)
>
> Apart from that if you browse to the current gitstat page
> (http://tree.celinuxforum.org/gitstat/chart.php?chart_parameter1=1&submit=1&setybase=700&prevperiod=16)
> you'll also see that 700 is not correct.
>
> One thing we could do is use the outcome from the above sql query, round that up
> to a nice number and set that as ybase? The downside is that we have to execute
> the query for every page (chart.php?chart_parameter1=1) as it's not 'globally' used.
>
> 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
>

[Gitstat-devel] [bug 1785778] sql query to get the maximum commits

[Paul V. <pau...@gm...>]

Hi,

(This relates to bug 1785578 'ybase is set fixed for "number of changesets" graph')

I've figured out the sql statement to get the maximum number of commits in the 
changeset:

mysql> select max(maxcommits) from (select
count(DATE_FORMAT(FROM_UNIXTIME(commitdate),'%Y%m%d')) as maxcommits
from ChangeLog group by
DATE_FORMAT(FROM_UNIXTIME(commitdate),'%Y%m%d')) as t1;
+-----------------+
| max(maxcommits) |
+-----------------+
|             733 |
+-----------------+
1 row in set (0.22 sec)

You see even the '700' that is currently set for the linux kernel is not enough ;-)

Apart from that if you browse to the current gitstat page 
(http://tree.celinuxforum.org/gitstat/chart.php?chart_parameter1=1&submit=1&setybase=700&prevperiod=16) 
you'll also see that 700 is not correct.

One thing we could do is use the outcome from the above sql query, round that up 
to a nice number and set that as ybase? The downside is that we have to execute 
the query for every page (chart.php?chart_parameter1=1) as it's not 'globally' used.

Cheers,

Paul.

Re: [Gitstat-devel] [feature request 1783070] A list of things that are still Kernel centric

[<jun...@gm...>]

R29vZCBqb2IsCkl0IHNlZW1zIHRvIGJlIG5pY2Ugc29sdXRpb24uIQoKSSBkaWRuJ3QgYW5hbHl6
ZSB0aGlzIHBhdGNoIHlldC4KYnV0LCBJJ2xsIGNoZWNrIHRoaXMgcGF0Y2ggZGVlcGx5IGFuZCBJ
ZiBpdCB3b3JrcyB3ZWxsLApJJ2xsIGluY2x1ZGUgaXQgbmV3IHJlbGVhc2UuClRoYW5rcyBmb3Ig
eW91ciBjb250cmlidXRpb24uCgoKT24gOC8zMS8wNywgUGF1bCBWcmllbnMgPHBhdWwudnJpZW5z
LmdpdHN0YXRAZ21haWwuY29tPiB3cm90ZToKPiDAzMGkvcIgd3JvdGU6Cj4gPj4gVGhpcyBtZWFu
cyB0aGF0IGNyZWF0aW5nIHRoZSB0YWdsaXN0IGJhc2VkIG9uIGNyZWF0b3JkYXRlIHdpbGwKPiA+
PiBub3QgYWx3YXlzIGdpdmUgeW91IHRoZSBjb3JyZWN0IHNvcnRlZCBsaXN0Lgo+ID4KPiA+IEhp
Lgo+ID4KPiA+IFdoZW4gSSBoZWFyZCB5b3VyIHByb2JsZW0sIEkgdGhvdWdodCBzYW1lIHNvbHV0
aW9uIHdpdGggeW91ciBjb2xsZWFndWUncwo+ID4gQW55d2F5LCBJIHRoaW5rIHRoYXQgdGhlcmUg
aXMgbm8gZnJvbnQgZG9vciBpbiBjYXNlIG9mIHdyb25nIGNyZWF0b3JkYXRlLgo+ID4gSWYgeW91
IGZpbmQgZ29vZCBzb2x1dGlvbiwgbGV0IG1lIGtub3cgaXQsIHBsZWFzZS4KPiA+IEdvb2QgbHVj
ay4uIQo+ID4KPgo+IEhpLAo+Cj4gSXQgc2VlbXMgdGhlcmUncyBhIHZlcnkgZWFzeSBzb2x1dGlv
biEgU2VlIHRoZSBhdHRhY2hlZCBwYXRjaC4gKFRoaXMgaXMgd2l0aCBnaXQKPiB2ZXJzaW9uIDEu
NS4yLjQpLiBUaGUgcGF0Y2ggdG8gbGliLnBsIHB1dHMgdGhlIGxpc3Qgb2YgdGFncyBpbiB0aGUg
Y29ycmVjdCBvcmRlcgo+IGluIHRvIHRoZSB2X3RhZyB0YWJsZS4KPgo+IFRoZSBwYXRjaCB0byBw
YXJzZXQucGwgbWFrZSBzdXJlIHdlIHVzZSB0aGUgZGF0ZSBvZiB0aGUgY29tbWl0IChyZWZlcmVu
Y2VkIGJ5Cj4gdGhlIHRhZykgZm9yIHRoZSBlcG9jaCBmaWVsZC4gSSBoYXZlbid0IGZpbmQgYSBu
aWNlciB3YXkgd2l0aCBhbnkgb2YgdGhlIGdpdAo+IHRvb2xzIHRvIGdldCB0aGUgc2FtZSBpbmZv
cm1hdGlvbiBmcm9tIG9ubHkgb25lIGNvbW1hbmQuIFRoaXMgc2VlbWVkIHRvIGJlIHRoZQo+IGVh
c2llc3QgKHNldmVyYWwgZ2l0IGNvbW1hbmQgcHJvZHVjZSBuaWNlIG91dHB1dCBmb3Igbm90IDMg
dGhlIHdhbnRlZCBmaWVsZHMsCj4gb25seSBnaXQtY2F0LWZpbGUgZG9lcyB0aGF0KS4KPgo+IFdo
ZW4geW91IGxvb2sgYXQgaHR0cDovL3RyZWUuY2VsaW51eGZvcnVtLm9yZy9naXRzdGF0L3RhZy5w
aHAgeW91J2xsIGFsc28gc2VlCj4gdGhhdCB0aGUgZGF0ZSBmb3IgdjIuNi4xMS10cmVlIHVwIHRv
IHYyLjYuMTMtcmMzIGlzIHRoZSBzYW1lLiBJIHRoaW5rIHRoaXMgcGF0Y2gKPiBhbHNvIGZpeGVz
IHRoYXQuIEkndmUgb25seSBjaGVja2VkIGl0IG9uIHRoZSBrZXJuZWwgZ2l0LXRyZWUgd2l0aCB0
aGUgY29tbWFuZHMKPiB1c2VkLCBub3Qgd2l0aCBnaXRzdGF0IGl0c2VsZi4KPgo+IENoZWVycywK
Pgo+IFBhdWwuCj4KPgo+Cj4KPgo+Cg==

Re: [Gitstat-devel] [feature request 1783070] A list of things that are still Kernel centric

[<jun...@gm...>]

R29vZCBqb2IsCkl0IHNlZW1zIHRvIGJlIG5pY2Ugc29sdXRpb24uIQoKSSBkaWRuJ3QgYW5hbHl6
ZSB0aGlzIHBhdGNoIHlldC4KYnV0LCBJJ2xsIGNoZWNrIHRoaXMgcGF0Y2ggZGVlcGx5IGFuZCBJ
ZiBpdCB3b3JrcyB3ZWxsLApJJ2xsIGluY2x1ZGUgaXQgbmV3IHJlbGVhc2UuClRoYW5rcyBmb3Ig
eW91ciBjb250cmlidXRpb24uCgoKT24gOC8zMS8wNywgUGF1bCBWcmllbnMgPHBhdWwudnJpZW5z
LmdpdHN0YXRAZ21haWwuY29tPiB3cm90ZToKPiDAzMGkvcIgd3JvdGU6Cj4gPj4gVGhpcyBtZWFu
cyB0aGF0IGNyZWF0aW5nIHRoZSB0YWdsaXN0IGJhc2VkIG9uIGNyZWF0b3JkYXRlIHdpbGwKPiA+
PiBub3QgYWx3YXlzIGdpdmUgeW91IHRoZSBjb3JyZWN0IHNvcnRlZCBsaXN0Lgo+ID4KPiA+IEhp
Lgo+ID4KPiA+IFdoZW4gSSBoZWFyZCB5b3VyIHByb2JsZW0sIEkgdGhvdWdodCBzYW1lIHNvbHV0
aW9uIHdpdGggeW91ciBjb2xsZWFndWUncwo+ID4gQW55d2F5LCBJIHRoaW5rIHRoYXQgdGhlcmUg
aXMgbm8gZnJvbnQgZG9vciBpbiBjYXNlIG9mIHdyb25nIGNyZWF0b3JkYXRlLgo+ID4gSWYgeW91
IGZpbmQgZ29vZCBzb2x1dGlvbiwgbGV0IG1lIGtub3cgaXQsIHBsZWFzZS4KPiA+IEdvb2QgbHVj
ay4uIQo+ID4KPgo+IEhpLAo+Cj4gSXQgc2VlbXMgdGhlcmUncyBhIHZlcnkgZWFzeSBzb2x1dGlv
biEgU2VlIHRoZSBhdHRhY2hlZCBwYXRjaC4gKFRoaXMgaXMgd2l0aCBnaXQKPiB2ZXJzaW9uIDEu
NS4yLjQpLiBUaGUgcGF0Y2ggdG8gbGliLnBsIHB1dHMgdGhlIGxpc3Qgb2YgdGFncyBpbiB0aGUg
Y29ycmVjdCBvcmRlcgo+IGluIHRvIHRoZSB2X3RhZyB0YWJsZS4KPgo+IFRoZSBwYXRjaCB0byBw
YXJzZXQucGwgbWFrZSBzdXJlIHdlIHVzZSB0aGUgZGF0ZSBvZiB0aGUgY29tbWl0IChyZWZlcmVu
Y2VkIGJ5Cj4gdGhlIHRhZykgZm9yIHRoZSBlcG9jaCBmaWVsZC4gSSBoYXZlbid0IGZpbmQgYSBu
aWNlciB3YXkgd2l0aCBhbnkgb2YgdGhlIGdpdAo+IHRvb2xzIHRvIGdldCB0aGUgc2FtZSBpbmZv
cm1hdGlvbiBmcm9tIG9ubHkgb25lIGNvbW1hbmQuIFRoaXMgc2VlbWVkIHRvIGJlIHRoZQo+IGVh
c2llc3QgKHNldmVyYWwgZ2l0IGNvbW1hbmQgcHJvZHVjZSBuaWNlIG91dHB1dCBmb3Igbm90IDMg
dGhlIHdhbnRlZCBmaWVsZHMsCj4gb25seSBnaXQtY2F0LWZpbGUgZG9lcyB0aGF0KS4KPgo+IFdo
ZW4geW91IGxvb2sgYXQgaHR0cDovL3RyZWUuY2VsaW51eGZvcnVtLm9yZy9naXRzdGF0L3RhZy5w
aHAgeW91J2xsIGFsc28gc2VlCj4gdGhhdCB0aGUgZGF0ZSBmb3IgdjIuNi4xMS10cmVlIHVwIHRv
IHYyLjYuMTMtcmMzIGlzIHRoZSBzYW1lLiBJIHRoaW5rIHRoaXMgcGF0Y2gKPiBhbHNvIGZpeGVz
IHRoYXQuIEkndmUgb25seSBjaGVja2VkIGl0IG9uIHRoZSBrZXJuZWwgZ2l0LXRyZWUgd2l0aCB0
aGUgY29tbWFuZHMKPiB1c2VkLCBub3Qgd2l0aCBnaXRzdGF0IGl0c2VsZi4KPgo+IENoZWVycywK
Pgo+IFBhdWwuCj4KPgo+Cj4KPgo+Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IFRoaXMgU0YubmV0IGVt
YWlsIGlzIHNwb25zb3JlZCBieTogU3BsdW5rIEluYy4KPiBTdGlsbCBncmVwcGluZyB0aHJvdWdo
IGxvZyBmaWxlcyB0byBmaW5kIHByb2JsZW1zPyAgU3RvcC4KPiBOb3cgU2VhcmNoIGxvZyBldmVu
dHMgYW5kIGNvbmZpZ3VyYXRpb24gZmlsZXMgdXNpbmcgQUpBWCBhbmQgYSBicm93c2VyLgo+IERv
d25sb2FkIHlvdXIgRlJFRSBjb3B5IG9mIFNwbHVuayBub3cgPj4gIGh0dHA6Ly9nZXQuc3BsdW5r
LmNvbS8KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+
IEdpdHN0YXQtZGV2ZWwgbWFpbGluZyBsaXN0Cj4gR2l0c3RhdC1kZXZlbEBsaXN0cy5zb3VyY2Vm
b3JnZS5uZXQKPiBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9n
aXRzdGF0LWRldmVsCj4KPgo+Cg==

Re: [Gitstat-devel] [feature request 1783070] A list of things that are still Kernel centric

[Paul V. <pau...@gm...>]

이정승 wrote:
>> This means that creating the taglist based on creatordate will
>> not always give you the correct sorted list.
> 
> Hi.
> 
> When I heard your problem, I thought same solution with your colleague's
> Anyway, I think that there is no front door in case of wrong creatordate.
> If you find good solution, let me know it, please.
> Good luck..!
> 

Hi,

It seems there's a very easy solution! See the attached patch. (This is with git
version 1.5.2.4). The patch to lib.pl puts the list of tags in the correct order
in to the v_tag table.

The patch to parset.pl make sure we use the date of the commit (referenced by 
the tag) for the epoch field. I haven't find a nicer way with any of the git 
tools to get the same information from only one command. This seemed to be the 
easiest (several git command produce nice output for not 3 the wanted fields, 
only git-cat-file does that).

When you look at http://tree.celinuxforum.org/gitstat/tag.php you'll also see
that the date for v2.6.11-tree up to v2.6.13-rc3 is the same. I think this patch
also fixes that. I've only checked it on the kernel git-tree with the commands
used, not with gitstat itself.

Cheers,

Paul.

Re: [Gitstat-devel] [feature request 1783070] A list of things that are still Kernel centric

[<jun...@gm...>]

>This means that creating the taglist based on creatordate will
>not always give you the correct sorted list.

Hi.

When I heard your problem, I thought same solution with your colleague's
Anyway, I think that there is no front door in case of wrong creatordate.
If you find good solution, let me know it, please.
Good luck..!

On 8/30/07, Paul Vriens <pau...@gm...> wrote:
> Hi,
>
> Just a list of things I've found so far
>
> - several graphs/statistics use fixed header strings
> - tags are checked for being "< 8" when statistics are being generated
>
> I know that the "<8" works fine for the kernel and gets rid of the release
> candidates but it's highly inflexible.
>
> Another thing related to this. Wine was changed from CVS to GIT somewhere at the
> end of 2005. Everything was imported to GIT but the tags are not necessarily of
> the correct date. This means that creating the taglist based on creatordate will
> not always give you the correct sorted list.
> One of our Wine developers came up with the idea to:
> ==
> A possible solution would be to have gitstat check the commit referenced
> by the tag; that one has the right date. E.g "tag wine-0.0.2" references
> "commit 2c25c3e9442c69bd2402f94f264f0aafa58b00e0" which has as
> "CommitDate: Tue Jun 29 16:33:12 1993 +0000".
> ==
> Another thing that is maybe only relevant for Wine is that the structure of the
> versioning changed over time:
>
> first wine-0.0.2 -> wine-0.7
> then wine-<yymmdd> (from wine-940201 to wine-991212)
> then wine-<yyyymmdd> (from wine-20000109 to wine-20050930)
> now wine-0.9 0> wine-0.9.44 (current version).
>
> The tags are named the same of course.
>
> I don't know yet how to solve the above issues but will keep investigating.
>
> 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
>

[Gitstat-devel] [feature request 1783070] A list of things that are still Kernel centric

[Paul V. <pau...@gm...>]

Hi,

Just a list of things I've found so far

- several graphs/statistics use fixed header strings
- tags are checked for being "< 8" when statistics are being generated

I know that the "<8" works fine for the kernel and gets rid of the release 
candidates but it's highly inflexible.

Another thing related to this. Wine was changed from CVS to GIT somewhere at the 
end of 2005. Everything was imported to GIT but the tags are not necessarily of 
the correct date. This means that creating the taglist based on creatordate will 
not always give you the correct sorted list.
One of our Wine developers came up with the idea to:
==
A possible solution would be to have gitstat check the commit referenced
by the tag; that one has the right date. E.g "tag wine-0.0.2" references
"commit 2c25c3e9442c69bd2402f94f264f0aafa58b00e0" which has as
"CommitDate: Tue Jun 29 16:33:12 1993 +0000".
==
Another thing that is maybe only relevant for Wine is that the structure of the 
versioning changed over time:

first wine-0.0.2 -> wine-0.7
then wine-<yymmdd> (from wine-940201 to wine-991212)
then wine-<yyyymmdd> (from wine-20000109 to wine-20050930)
now wine-0.9 0> wine-0.9.44 (current version).

The tags are named the same of course.

I don't know yet how to solve the above issues but will keep investigating.

Cheers,

Paul.

Re: [Gitstat-devel] How to deal with database changes between versions

[<jun...@gm...>]

Hi..

Actually, I made that script.
I forgot to upload that script :-)

1. Run Mysql and select your database.
2. type "ALTER TABLE `Memcategory` ADD `filename` VARCHAR( 80 ) NOT
NULL DEFAULT '0';"

or just use this script

[gitstat]# mysql -u username -p dbname < ./gitstat.update.sql


- gitstat.update.sql
-----------------------------------
use database; # your database name

ALTER TABLE `Memcategory` ADD `filename` VARCHAR( 80 ) NOT NULL DEFAULT '0';"
-----------------------------------

Thanks,


On 8/30/07, Paul Vriens <pau...@gm...> wrote:
> Hi,
>
> Thanks for 0.0.2 ! I'll have a go at it.
>
> The database layout changed (a bit) between 0.0.1 and 0.0.2 (addition of the
> filename field). It would be nice if documentation (or better yet a scripts) is
> provided to show how to amend the database.
>
>  From the above you can see I'm not a DB wizard.
>
> 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
>

[Gitstat-devel] How to deal with database changes between versions

[Paul V. <pau...@gm...>]

Hi,

Thanks for 0.0.2 ! I'll have a go at it.

The database layout changed (a bit) between 0.0.1 and 0.0.2 (addition of the 
filename field). It would be nice if documentation (or better yet a scripts) is 
provided to show how to amend the database.

 From the above you can see I'm not a DB wizard.

Cheers,

Paul.

Re: [Gitstat-devel] Indentation of the code

[<jun...@gm...>]

Hi Paul.

There is no standard indentation for gitstat.
but now, we used tabs for indenatation in gitstat code.
gitstat is still early stage. It is just v0.1 :)
Let's make many standard for gitstat.

Thanks.

[Gitstat-devel] Indentation of the code

[Paul V. <pau...@gm...>]

Hi,

Does gitstat adhere to some kind of standard indentation? FWIW I would prefer 
4-spaces indentation instead of the tabs (and I'm not sure it's tabs everywhere).

Cheers,

Paul.

[Gitstat-devel] list test

[Soon-Son Kwon(Shawn) <ks...@kl...>]

This is a test message

Please ignore...

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