Releases for Version Control API -- CVS backend

Bug fix release. In short, this makes the xcvs-* trigger scripts work again (while adding a bit of helpful output for the committer). No changes otherwise, apart from fixing #366318: CVSModule_Compatibility missing component.

Companion testing release to Version Control API 6.x-1.0-alpha1. Should work just as flawlessly as versioncontrol_cvs 5.x-2.0, but like Version Control API itself, no guarantees about possible API or functionality changes until a stable 6.x-1.0 can be given. Therefore, this alpha1 might not work with future alphas, betas, release candidates or stable releases. (Or it might - who knows.)

Anyways, the upgrade path is there, and there hasn't been a release for Drupal 6 before, so you probably won't lose anything by trying this out and reporting bugs. Let's look forward to Drupal-core-like adoption numbers for the 6.x version - enjoy, and consider to contribute!

Despite being an -rc2, there have been a good number of improvements since -rc1.

• Recording commit information from 'cvs log' (a.k.a. log fetching) was broken in the previous release, that's fixed in this one.
• The CVS backend now supports basic repository browsing via Repoview, though only for the latest revisions on HEAD.
• A cvs.module compatibility layer (implemented as optional add-on module) has been added, so that the 'cvs' menu path (e.g. "http://drupal.org/cvs") keeps working when upgrading from cvs.module. Granted, without the update script being finished this will be of limited value, but we'll need that compatibility layer for Drupal 6 anyways, so why not add it now.
• On the coding side, lots of refactoring has been done, splitting out the code interfacing with CVS into a Drupal-agnostic helper library (which also means it won't need to be ported).

Companion release to the great new Version Control API 5.x-2.0-alpha1. Apart from user-invisible porting work and a more reliable mechanism to recognize re-additions of files as additions instead of modifications, the xcvs-* scripts have been improved in their branch/tag handling, which allows to control deleted tags using generic Version Control API facilities and fixes a couple of problems with tag moves. This release also allows to prevent the creation of new branches through obscure CVS backdoors, and is able to drop most of its database tables in favor of the new centralized ones in the API module.

The upgrade routines seem largely ok, but might leave over some unnecessary database rows. I'll probably refine them a bit more until the final 5.x-2.0 release. On the other hand, drupal.org's usage statistics show no users for the CVS backend at the moment, so I've probably written the extensive database upgrade code for myself only. But hey.

In a nutshell, if you use Version Control API 5.x-2.x, you want to have this - the CVS backend was never in a better state than it is now. (If it weren't for the huge amounts of code for the upgrade path, this release would even come with significantly less lines of code than the 5.x-1.x version.)

It works! Ship it!
...well it still doesn't contain CVS log parsing (I'm working on it, though) but it now comes with a README.txt for the xcvs-* hook scripts, and fixes a major bug in capturing commits. On the other hand, the option to combine multiple directory hook invocations into one commit (or tag/branch) message is now compulsory, thus the concerned option has been removed.

Please update.

Companion release for Version Control API 5.x-1.0-rc3 (which is required for this release): fix Postgres support, make the uninstallation routine work properly, and don't attempt to handle repository and account forms of other backends.

Companion release for Version Control API 0.9-rc1, introducing no real features but keeping up with API and altered form changes.