The largest part of this should probably be a patch for Commit Log to decouple commit constraints and HTTP request attributes. So Commit Log should be able to deliver a page just by calling commitlog_commits_page($constraints) (which is probably getting renamed to commitlog_page() later on) and reconstruct the attributes array after that. (The attributes array is required for the link to the RSS feed.)
Once that is done, a legacy menu path will only be an issue of parsing the request attributes into a different constraints array than Commit Log does natively.
Commit Log 5.x-2.x has commit constraints and HTTP request attributes decoupled, as mentioned above. I just added a compatibility module (versioncontrol_cvslog_compat) to the CVS backend which implements the 'cvs' path on top of Version Control API, and redirects 'cvs-application' to 'versioncontrol/register'. So this issue is fixed now.
Comments
Comment #1
jpetso commentedThe largest part of this should probably be a patch for Commit Log to decouple commit constraints and HTTP request attributes. So Commit Log should be able to deliver a page just by calling commitlog_commits_page($constraints) (which is probably getting renamed to commitlog_page() later on) and reconstruct the attributes array after that. (The attributes array is required for the link to the RSS feed.)
Once that is done, a legacy menu path will only be an issue of parsing the request attributes into a different constraints array than Commit Log does natively.
Comment #2
jpetso commentedCommit Log 5.x-2.x has commit constraints and HTTP request attributes decoupled, as mentioned above. I just added a compatibility module (versioncontrol_cvslog_compat) to the CVS backend which implements the 'cvs' path on top of Version Control API, and redirects 'cvs-application' to 'versioncontrol/register'. So this issue is fixed now.