| 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 | 06/08/2005 (1074 days ago) |
| Due | |
| Updated | 02/15/2008 (92 days ago) |
| Assigned | |
| Resolved | |
| Attachments | |
| Milestone | |
| Patch |
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)
Bounty added:http://horde.org/bounties/details.php#chora_monitor
> 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 :-)
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.State ⇒ Accepted
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. :)Priority ⇒ 1. Low
Summary ⇒ CVS Activity Log/Monitor
Queue ⇒ Chora
State ⇒ New
Type ⇒ Enhancement
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.