Version Control API and family changes

Project information

Description

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 management system for development.
This propose started like a jpetso propose, after that I made one based on these ideas.

Project schedule

update: after asking my mentor and co-mentor about, we got a new plan

• Phase 0: April 23 - May 23: Community Bonding Period (Related issues: Convert Version Control API to OOP)
  • Make a draft about interaction between classes, based on actual code
  • Think about testing, and how to use it inside versioncontrol modules
  • IRC/VoIP meeting with mentor about the draft
  • worry about all legal stuff( fax my Student Foreign Certification and Proof of Enrolment to Google, etc)
• Phase 1: May 25 - June 7 Convert Version Control API to OOP (2 weeks)
  Make versioncontrol modules OO(July 9th - July 26th)
  • see if there 's some special coding standard to OOP, if now follow views :D
  • Transversal task, implements clases: VersioncontrolBackend, VersioncontrolRepository, VersioncontrolItem, VersioncontrolLabel, VersioncontrolBranch, VersioncontrolTag, VersioncontrolAccount, VersioncontrolOperation
  • Complete tests for versioncontrol to verify all is working and convert remaining parts to OO code(now - July 12th)
    • on master branch
    • on oop branch
  • Backend class(July 13th - July 16th)
    • make git backend work with it
  • Conversion to interfaces(July 17th - July 26th)(see thinking on interfaces(aka define them))
• July 6-13: Midterm Evaluation
• Phase 2: July 27th - August 9th Improve user authentication (1 week)
  • .htaccess/.htpasswd auth
  • SSH keys auth
• August 17: Final Evaluation
• postponed(out of GSoC)
  • cvs backend working
  • subversion backend working
  • Phase 2: Some refactor of the project node integration module(if time allows it).
    • sync to oop changes if applicable
    • DVCS features
      • manage private branches in cloned repositories
      • Let clone manually by some drupal user(like clone from github)
      • manage merge or pull (gitorious vs github) requests, completing the cycle: fork, improve, merge.
  • Phase 3: Work with the community to get a DVCS deployed on drupal.org
    • Work for getting a DVCS running on d.o(after GSoC ends)
    • join forces with Daniel Hackney at his project.
    • implementing whatever is required to get core development under a DVCS

How are we working

• We, Daniel and me, are two students with some kind of related projects, so we are having Sunday IRC meetings at #drupal-vcs on freenode, at 18:30 UTC with mentors and anyone who wants to help(tracked on d.o, from g.do)
• We have clones of versioncontrol related projects at github. master branches follow stable cvs branch and it's also the place where I directly apply my fixes. oop branches are the converting to OO code stacks. Here are my clones:
  • versioncontrol: master and oop branches
  • versioncontrol_git: master and oop branches
• Tweeting work of the day (take a look on #vcs on my twitter)

• Making Weekly updates here(g.d.o), logged at a versioncontrol issue on d.o(here for me)

  • WU1: from design to code
  • WU2: bulk updates to OOP (aborting stable plans for oop branch)
  • WU4: lots of littles to let start working repositories and vcs accounts
  • WU6: some tests and fixes for stabilization
  • WU7: fixing all around
  • WU9: rethinking interfaces, oop-dbtng and autoload
  • WU12: more interfaces, repo urls, documentation, fixes, loaders, rebasing

• Talking as much as we can to avoid losing common targets