This project objective is provide all tools to make it easy a possible drupal.org migration to another Version Control System(aka VCS). By the way, after this, drupal VCS's interaction will be improved, so it provides more flexibility to use it as project managment system for development.
This propose started like a jpetso propose.
Some drupal.org developer tools, like the auto-releasing module versions feature, are CVS dependent, which is one of the reasons why drupal project is using CVS now.
Drupal developers are used to recognize others work, so it would be really natural to use a Distribututed Version Control System(aka DVCS) where this concept is implicit(authors and commiters can differ).
On GSoC 2007, Jakob Petsovits developed Version Control API, making it possible to integrate various VCS backends in drupal.
I'm really interested on VCS's, and specially dreaming about commiting to drupal with git(that's why I wrote a guide for maintainers).
Now, there are some details that make Jakob solution not production ready, so I want to take it all to this state.
- Jakob Petsovits (jpetso), who proposed the original idea, and proposed himself as a mentor.
- Any other drupal developer that really like VCS's( any help would be appreciated).
(2 weeks) - Convert Version Control API to OOP
To make the code more natural, because it's wrote to be OOP.
All functions which are backend helpers or with API points(aka with module_invoke's, probably only from versioncontrol.module) on a singleton or "static"(abstract class with static methods in PHP) class VersionControlAPI. E.g.: versioncontrol_backend_implements() or versioncontrol_get_backends().
Leave all drupal related functions(hook_menu, hook_init, etc.) outside the class and maybe also the versioncontrol hooks implemented by itself (e.g.: versioncontrol_versioncontrol_operation_constraints_alter()).
All functions that should/must be called by backends on a VersionControlBackend abstract class, which will be the parent of all backends.
Each entity, like it's described on versioncontrol project OVERVIEW.txt, will have a class: VersionControlRepository, VersionControlItem, VersionControlLabel, VersionControlAccount, VersionControlOperation; and each one will have their related methods inside.
Following OOP aproach, the versioncontrol submodules, like commitlog, could be converted to interfaces, that the backend could implement.
I talked with Larry(Crell), the author of handler module, who is working on a 3.x approach for Drupal 7, and he suggest me it would be a good idea to defer that integration until D7 branch(both Jackob and Larry think the same).
(2 weeks) - Update cvs, subversion and git backends according to API changes.
Update modules and maybe use PHP ArrayAccess interface until all changes were made.
(1 week) - Improve user authentication.
Implement two methods: .htaccess/.htpasswd and SSH keys.
(4 weeks) - Some refactor of the project node integration module.
Let the module to manage the most central aspect of distributed version control systems: private branches in cloned repositories. Also add merge request feature from <a href="http://gitorious.org>gitorious, completing the cycle: fork, improve, merge.
(2 weeks) - Work with the community to get a DVCS deployed on drupal.org
First for drupal core(like Jakob said, it seems contrib isn't going to be switched anytime soon), implementing whatever is required and makes sense for such a move.
Name: Marco Antonio Villegas Vega
I've been using free software since 2004, drupal since 2006.
On work time, I used to contribute to Dokeos E-learnig plataform, specially on xapian search engine integration.
marvil07 on drupal.org, groups.drupal.org, freenode