Project information
Project page on drupal.org: http://drupal.org/project/versioncontrol (and related modules)
Student: Daniel Hackney (dhax on d.o, dhax@drupal.org on g.d.o)
Mentor: Tony Narlock (skiquel)
Co-mentor(s): Jakob Petsovits (jpetso)
Application link (Google): http://socghop.appspot.com/student_proposal/review/google/gsoc2009/dhack...
drupal.org issues: http://drupal.org/project/issues/search?issue_tags=gsoc2009-dhax
Current status
Planning/background work.
Overview
I will be making several changes to Drupal's Version Control System (VCS) integration to make it a fully viable replacement for the current CVS-specific system used. The ultimate goal would be to develop alternate backends such as Subversion and Git to the point that they could be used in lieu of CVS for managing the Drupal core and the contributed modules. Additionally, I will implement web-based support for creating branches of projects, similar to Launchpad.
Description
There are six distinct components to this project: creating hook scripts for SVN to allow Drupal to react to SVN-triggered events, cleaning up the Git backend and writing hook scripts for Git, integration with the Rules module, support for managing multiple code branches per project, cleanup of the Mercurial backend and creation of hook scripts for Mercurial, and the creation of a Bazaar backend.
The Subversion hook scripts are the simplest aspect of the project, and would be done first, providing a good introduction to developing Drupal and the VCS interface. Subversion (and all other VCS systems) have a number of hooks which run scripts before and after various events take place. When such an event takes place, Subversion first runs the pre-event script (if it exists) and if the script completes successfully (with an exit value of zero), then the event continues. This can be used to prevent certain users from committing to particular paths of a repository or ensure that committed code follows certain coding conventions. The post-event hooks are triggered after an event completes and can be used for things like automatic notifications of users subscribed to a project.
My work would be to write scripts which implemented these hook scripts for communication with Drupal. They would be initiated by the Subversion process and expose the Subversion events to the Drupal Version Control API. From there, actions such as updating Drupal's cache of the repository layout or automatically closing bug reports mentioned in the commit message could be implemented on top of the abstracted interface. This functionality is essential for any VCS to be considered for use on the main Drupal.org site. All-in-all, this part of the project should take about a week or less to complete, as it is very similar to the existing CVS hooks and there is an existing partial implementation.
Writing the Git backend and hook scripts will allow the Drupal VCS interface to track Git-based repositories. This is nearly identical to the Subversion hook scripts, except that the Git backend needs some cleanup. The backend allows Drupal to query the Git (or other VCS) repository for information such as a log of commits, files changed in a particular commit, or annotation information (such as "git blame" or "svn blame"). In short, hooks are initiated by the VCS and interfaces need to be written to allow Drupal to respond to these requests, and backends allow Drupal to initiate requests to the VCS and make sense of its output. The Git backend and hooks should take a full week to complete.
The Rules module allows Drupal site admins to set up complex actions triggered by a number of events such as the creation of a new node or when a user logs out. There are a number of events, conditions and actions which would be useful for a Drupal administrator to be able to connect. For example, an administrator could send an email each time a commit was made or close a bug report when its number is mentioned in a commit message, each without having to write any PHP code. This would involve exposing various events, actions and conditions from the VCS layer to Rules to allow site administrators to build complex behaviors into their sites without the need for PHP knowledge. This should take about a week.
The largest single component of this project, managing multiple VCS branches per project, will take roughly four weeks to complete, and will expose the full potential of Distributed Version Control Systems (DVCS) to users and developers. DVCSs make maintaining multiple branches of the same project much easier and more viable, and exposing that power to Drupal will allow more efficient development on the Drupal core and modules. Developers will be able to work on independent branches of development without stepping on each others toes. Additionally, with better management of branches, the bar for giving out commit access could be lowered and managed in a more fine-grain way, by granting users access on a per-branch basis. This would allow users to commit changes to a personal branch and then request a merge, rather than the current approach of attaching patches to bug reports.
Managing multiple branches per project will require a number of user interface modifications, in addition to refinements of how repository access permissions are handled (to enable write access to some, but not all branches of the same repository).
Writing the Mercurial and Bazaar backends will be mostly the same as the Subversion and Git backends, except that the Mercurial backend is already underway, and the Bazaar backend is completely non-existent. Completion of these two components would allow projects to be managed using these two DVCSs, which some users prefer. Since Git seems to be the currently favored DVCS for Drupal developers, the creation of these two backends is a lower priority and will only be attempted once the Git and SVN backends are complete and functional.
Project schedule
Week of May 24 - June 7: Hook scripts for SVN- Took a week longer than expected to get up-to-speed, so all dates have been pushed back a week.
- Included SimpleTests (for hooks only, not for SVN backend in general).
pre-commitandpost-commithooks were the only ones that made sense for SVN, so those were the only ones added.
- Week of June 7 - June 14: Git backend and hooks
- Currently work in progress.
- Git-php integration is not as sophisticated and git hooks are mote complicated, so it is taking longer.
- Contemplate writing gitlib (in the style of svnlib to make interaction between Git and PHP easier.
- Week of June 14 - June 21: Rules module integration
- Add events, conditions, and actions from VersionControl API to the Rules module
- Weeks of June 21 - July 12: Multiple project branches
- Add support for a more DVCS development style with multiple code branches within a project.
- Allow commits to branches or repositories (depending on the decision) by non-admin users. Admin users can choose whether to pull those changes into the master branch or repository.
- Can allow for a relaxation of Drupal.org's strict commit restrictions (which are needed for CVS).
- July 6-13: Midterm Evaluation
- Week of July 12 - July 19: Mercurial backend and hooks
- Weeks of July 19 - August 2: Bazaar backend and hooks
- August 17th: Final evaluation