version control api

Abstract

Although Drupal has switched to Git for its Version Control needs for about an year, yet the workflow is by and far patch based, when it comes to collaborating. While some choose the path of creating sandboxes and then create an issue in the main project, yet we are far from using the power of distributed workflow that Git offers us. The following proposal aims at providing the base of using Git-like workflow while collaborating on projects.

Previous Discussion(Summary)

The detailed description of repo-families can be found here[2].

Abstract

The Version Control API is an engine for Drupal integration with a variety of version control systems. It delivers an interface to these systems for use with various development-oriented modules, like Project.

Short description

The Version Control API allows development-specific modules to interface with the server side of version control systems. We currently still lack the ability to really see what’s going on with a repository.

An activity stream is an overview of all actions in a system that are interesting to a user from his or her perspective.

This project includes a complementary module to the Version Control API that logs every change to every repository, displaying them and processing statistics about them.

One part of my GSoC is to add support (of some sort) to VersionControl API for having multiple branches within a project (like a drupal.org project) with different user permissions. The idea is to allow a more DVCS-like workflow, where people can work independently on their own branch and then request an admin user to pull their changes into the master repository. I won't be starting this for a few weeks, but I wanted to get a discussion going about what it should look like.

Whoa, seems I skipped one set of logs again. Anyways, here's what we discussed last Sunday. This time with even nicer formatting.
Topics include:

• Conceptual issues for dhax's Git hooks (→ using the 'update' hook for permission control so that branch pushes don't depend on other branches' validity)
• The future of source items in the main API module (→ we want them as an optional bonus instead of a log-parse-time requirement)
• Proper merging of commits from Git into CVS (→ git cvsexportcommit allows an "-m" option for prefixing a string to the commit message)

Ok, so gathering #2 was largely technical and a bit unfocused at times, I won't post that one because it probably won't make such a good read if you haven't been in #drupal-vcs in the first place. Today's gathering #3 seemed more interesting to me, and focused largely on workflow issues. The core outcome (imho) is that the students will post short daily "micro-blogging" updates so that mentors stay up to date on the status even if no progress is made for any reason. Using a dedicated d.o issue and/or Twitter respectively identi.ca for these purposes. We also follow each other on Github now.

If all goes well, the students should be pushing out their first weekly updates by tomorrow evening, which will also be tracked in a d.o issue (as discussed earlier). Complete log of today's IRC meeting follows below.

While perusing the xcvs code, I noticed that xcvs-config.php had a fair amount of code which was very non-cvs-specific, like xcvs_bootstrap and xcvs_get_temp_directory. These functions will be mostly or entirely identical for all backend hooks, so why not move them somewhere common, like in the versioncontrol module.

It might make loading a bit more complicated, and it really isn't that much code (and seems fairly unlikely to change, so there won't be a big problem of keeping a lot of copied code in sync), so it probably isn't worth it if there is too much involved.

At least for the duration of SoC 2009, we're shifting upstream development of Version Control API to Github, with regular syncs from and to Drupal CVS. Feel free to fork one or more of the modules into your own branch, commit and push your own changes without upstream approval, and send merge pull requests when the feature is done.

This move is being done because both of our SoC students as well as at the majority of mentors is fluent in Git, and the simultaneously developing branches is made a lot easier with a distributed version control system.

Our first all-inclusive meetup, featuring both students (marvil07 and chrono325, now known as dhax) and two of three mentors (jpetso and sdboyer-laptop). Covered topics include development goals, workflow issues (using "gsoc2009" as well as "gsoc2009-marvil07" and "gsoc2009-chrono325" tags for issues), student development repositories (pushing everything onto Github for the time being), and how to manage further communication (there's going to be a weekly IRC meeting, every Sunday at 18:30 UTC). All subsequent logs will be tracked in the d.o issue http://drupal.org/node/470722.

For everyone at DrupalCon - just in case you missed the BoF wall or the DrupalCon BoF forums - well, you guessed it: there's a Version Control API BoF taking place on Friday at 3:45, in room 141 of the convention center. Be there, or be triangular!