Releases for Version Control API

I know I just released the last beta only five days ago, but this one changes the way that the operation query (important for lots of Version Control API code) is constructed, and should therefore get a new release. Also, those changes enable to get rid of a rather serious scalability bottleneck, which is probably also something that you might want to have. And third, the tandem release of versioncontrol_project (6.x-1.0-beta2, which sports the same kind of improvements and a few important bugfixes) depends on the changes in here.

For developers: there's a new hook in there - hook_versioncontrol_operation_constraint_info() - which enables you to add new "native" SQL constraints for the operation query. Also, hook_versioncontrol_alter_operation_constraints() has been renamed to hook_versioncontrol_operation_constraints_alter(), for naming consistency with other alter hooks.

Finally, I think that the feature set desired for an initial 6.x-1.0 release has about been reached, and I'm only keeping this beta in case some API changes are still necessary. Apart from that, this release is probably the nicest version of Version Control API to date. r0xx0rz.

Fixing more trivial errors. Oh my. At least there should be no syntax errors in any file now, which means the actual testing can begin. I'd like to test stuff out more by myself, but I need to get other stuff done before I can get back to Version Control API. Also, the link to the non-functional beta1 release notes which explain what you can expect from this 6.x-1.x series in the first place.

Ok, so with this release all parts of Version Control API have been ported and should work, as well as the CVS and SVN backends. (versioncontrol_project most probably needs some more adaptations, and will be finished when the Project module's own Drupal 6 port is nearing completion.)

Rules (previously workflow_ng) support is in place again, now even with support for rule-based sending of notification mails (yay). All API changes that were required for a proper Drupal 6 port are in, I don't expect further API changes until a 6.x-2.x branch starts off. Features are supposed to be just on par with the 5.x-2.0 version.

It's now up to you to test the hell out of this release, and report plenty of bugs in the issue queue. I've tried to be thorough on the code, but I haven't done a lot of testing. Mails, CVS account import/export, as well as the Commit Restrictions and Version Control Account Status modules are completely untested at this time and might fail loudly or in a more subtle way. Your testing is needed in order to make sure everything works as it should.

The definite release of Version Control API for Drupal 5! Compared to 5.x-2.0-rc2, this one just contains a few bug fixes that I noticed while porting the code to Drupal 6. Here's what changed since the last release candidate:

• Important: Prepared the database schema for the 6.x upgrade - a few indexes weren't named quite the way that the Schema API based table specification in 6.x-1.x would create them. Before upgrading to any 6.x version, you need to install this 5.x-2.0 release and run update.php.
• Fixed watchdog entries when creating, updating or deleting either repositories or VCS accounts.
• Fixed reapplication mail subject in the Version Control Account Status module. (Now with " [reapplication]" appended, like it should.)
• Fixed access permissions to the private VCS account edit page, which might have been denied before in certain cases although access should have been possible.

And because it's the "final" 5.x-2.0 release, let's rehash what has been written in the 5.x-2.0-alpha1 announcement already:

This release is dedicated to Sam Boyer, who saved Version Control API with lots of interest, enthusiasm and persistence. Dude, you rock. So, the release announcement.

We decided to move on to the Drupal 6 port as soon as possible, so instead of adding a ton of features to the now reinstated 5.x version, you'll get 5.x-2.0 the way it is now: at least as nice as 5.x-1.0, and most importantly with much more sanity under the hood. Upgrading to this release is recommended to everyone using Version Control API with Subversion and/or CVS - I am not aware of any regressions, but doing a release candidate is probably still a good idea. If you find any issues with this release, please report it to the issue queue.

A slightly more detailed description of the changes can be found in the 5.x-2.0-alpha1 release announcement, repeating it here probably doesn't make all too much sense. (No noteworthy changes since then, too.)

The big 5.x-2.x revamp, now stable and in feature freeze. A vastly improved database structure promises similarly vast performance improvements and querying possibilities that you didn't dare to even wish for the 5.x-1.x branch. Unfortunately, those changes had a broad impact and broke the whole framework for months. But we managed to get it back on track, and the result is 5.x-2.0 (or later patch-level releases). This branch should now be just as safe to use as any 5.x-2.x release, although it's probably still a better idea to stick to official releases.

Bugfix release. It includes only one real fix (actually returning the result for the versioncontrol_insert_{commit,branch_operation,tag_operation}() functions) but that fix is required for versioncontrol_svn to work correctly. There's also an API documentation fix in versioncontrol_fakevcs.module, but that one doesn't affect the correct function of the modules.

So, the Version Control API doesn't yet live up to all that it promises to achieve, but it works well enough for what it does and should really get a stable release before more of the looming large database changes come up again. At this point, there are working backends for CVS, Git and Mercurial - all of them offer commit log functionality, and CVS also supports access control. Project node integration (versioncontrol_project) provides an optional extension to the core functionality with a mapping of commits to projects and associated access control rules.

Compared to a project*/cvslog based solution, Version Control API & friends currently still lacks integration with project release nodes and probably has suboptimal performance for large repositories with huge masses of commits. Both of those issues will be taken on for the 6.x version, and if you just need a log viewer for one or more (simultaneously) of the above version control systems then you might already find this set of modules quite appealing :)

Fix a few issues (including some rather severe ones) that I discovered while starting the Subversion backend:

• Postgres support should be working now.
• Make sure that the versioncontrol_delete_{repository,branch,tag,commit}() functions work from [vcs_backend]_uninstall().
• Make sure that disabled backends never cause *more* results to be retrieved by the query functions. Do not use more than one backend without upgrading to this release, as it might delete your version control related data on uninstalling a backend.
• Make sure that the FakeVCS backend never handles form value extraction hooks if it hasn't altered the form beforehand.
• Fix a typo in the FakeVCS backend.
• Polish for the repository edit form: require a repository name, and remove a duplicate form element description.