6.0.0-git
2019-03-22

[#2112] CVS Activity Log/Monitor
Summary CVS Activity Log/Monitor
Queue Chora
Queue Version HEAD
Type Enhancement
State Accepted
Priority 1. Low
Owners
Requester jhart (at) webroot (dot) com
Created 2005-06-09 (5034 days ago)
Due
Updated 2009-05-08 (3605 days ago)
Assigned
Resolved
Milestone
Patch No

History
2008-02-15 06:03:25 Chuck Hagenbuch Comment #6 Reply to this comment
Some ideas from Michael Naberezny via IRC log:



[16:39] <mnaberez> seems chora could just page cache, and all the 
commit hook would need

to do is invalidate the cache

[16:41] <mnaberez> that doesn't help with the timeline, but that's 
something that can

just be generated once with `svn log` and page cached, and then 
invalidated by the hook.

reporting and storing all kinds of stats is hard

[16:43] <cjh> also harder for cvs

[16:44] <mnaberez> cjh: in what sense?

[16:45] <cjh> generating a timeline for the whole repository in CVS is 
a royal pain

[16:49] <mnaberez> cjh: if the stats were generated per commit by the 
repository hook,

features like timeline would only work from the time after the hook 
was installed.  it

seems you'd need to collect that back information from the repository anyway.

[17:03] <cjh> right, but you could do it once and then update it incrementally

[17:03] <cjh> instead of all at once when it was invalidated

[17:06] <mnaberez> cjh: this is why i suggested that it might 
invalidate a page cache.

if the hook reported a file changed, you would invalidate the cached 
page for that file's

directory, and invalidate the first page of the timeline.  that's 
straightforward, and

then the same mechanism is always used to generate those pages

[17:07] <cjh> ah

[17:13] <mnaberez> cjh: i think collecting statistics would be much 
more interesting, but

also much harder.  i guess it depends on what the goals are (make 
chora faster vs more

features)


2005-06-09 16:28:18 jhart (at) webroot (dot) com Comment #4 Reply to this comment
All these features need cvs commits to be tracked on the cvs servers.
None of these tools is working on the repository alone afaik, which
is what Chora currently does.
I'm looking closer at how CVSMonitor does their tracking, but this is 
true for cvstrac - it has a line in the loginfo file in the CVSROOT 
admin directory which prints out the relevant information ready for 
parsing.  I see this as the 'easiest' way to track checkins, 
especially since chora doesn't support remote repositories currently.   
If that is to change in the future, a different method would need to 
be found (going back to using cvsps, likely)



BTW, I'm having troubles with cvsps in chora for files right now... 
but thats an issue for a different bug report :-)
2005-06-09 08:46:33 Jan Schneider Comment #3 Reply to this comment
All these features need cvs commits to be tracked on the cvs servers. 
None of these tools is working on the repository alone afaik, which is 
what Chora currently does.
2005-06-09 02:10:36 Chuck Hagenbuch Comment #2
State ⇒ Accepted
Reply to this comment
Something like this would be great in Chora. I have to say that a 
patch would speed up inclusion of this feature immensely, though, 
since Chora is currently meeting our needs (for cvs.horde.org, 
cvs.php.net, etc.). And there's a lot of other stuff to do. :)
2005-06-09 00:28:20 jhart (at) webroot (dot) com Comment #1
Type ⇒ Enhancement
State ⇒ New
Priority ⇒ 1. Low
Summary ⇒ CVS Activity Log/Monitor
Queue ⇒ Chora
Reply to this comment
One thing we liked about cvstrac was the activity timeline 
(http://www.cvstrac.org/cvstrac/timeline) - ignore the ticket changes, 
but note the checkin log.



CVSMonitor's interface is even more complex 
(http://bugs6.perl.org/cgi-bin/cvsmonitor/cvsmonitor.pl?cmd=viewBrowseModule&module=perlpublic.parrot) and could even be 
preferrable.



I dont know if this type of view has been looked at for Chora, or if 
it would be better suited as a whole new Horde app, tightly integrated 
with Chora.

Saved Queries