You can subscribe to this list here.
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(10) |
Sep
(48) |
Oct
(7) |
Nov
(16) |
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
(27) |
Feb
(4) |
Mar
(6) |
Apr
(9) |
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
(1) |
2009 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <jun...@gm...> - 2007-09-04 00:40:37
|
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 > |
From: Paul V. <pau...@gm...> - 2007-09-03 16:42:56
|
이정승 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. |
From: Paul V. <pau...@gm...> - 2007-09-03 15:42:41
|
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. |
From: Paul V. <pau...@gm...> - 2007-09-03 15:19:08
|
??? 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 |
From: <jun...@gm...> - 2007-09-03 15:09:14
|
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. |
From: <jun...@gm...> - 2007-09-03 12:58:35
|
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 > |
From: Paul V. <pau...@gm...> - 2007-09-03 06:54:46
|
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. |
From: <jun...@gm...> - 2007-09-03 00:29:39
|
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== |
From: <jun...@gm...> - 2007-09-01 09:54:22
|
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== |
From: Paul V. <pau...@gm...> - 2007-08-31 12:11:00
|
이정승 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. |
From: <jun...@gm...> - 2007-08-31 01:08:10
|
>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 > |
From: Paul V. <pau...@gm...> - 2007-08-30 07:44:27
|
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. |
From: <jun...@gm...> - 2007-08-30 06:37:56
|
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 > |
From: Paul V. <pau...@gm...> - 2007-08-30 06:14:27
|
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. |
From: <jun...@gm...> - 2007-08-29 23:32:05
|
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. |
From: Paul V. <pau...@gm...> - 2007-08-29 08:46:27
|
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. |
From: Soon-Son Kwon(Shawn) <ks...@kl...> - 2007-08-17 05:33:29
|
This is a test message Please ignore... -- http://kldp.org/~kss |