version control api

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!

Overview: Make integration of version control systems with Drupal rock, and at the same time help out a module family that's going to be running on drupal.org soon.

Description:

drupal.org has great integration with CVS, including stuff like a commit messages page (which can also be viewed separately for each project), CVS account management, commit restrictions provided dynamically by the website, or automatic packaging of release tarballs just by specifying the CVS tag when creating the release node. All of that makes drupal.org an immensely powerful and easy to use platform for managing Drupal projects in CVS. As a downside though, all of that works only for CVS, and the fact that it doesn't cope with other version control systems is one major reason that drupal.org is still sticking with CVS all the way.

Version Control API was born as a Summer of Code project (the logs!) in 2007, and aims to provide version control integration for Drupal while not depending on any specific version control system (VCS), and being flexible enough for usage on sites other than drupal.org.

It's been a long time since I last posted an update on the state of the Version Control API, assuming we disregard short teasers on Planet Drupal. Since this last article, Version Control API nearly died during my attempts to wholly restructure the data model for practically everything involving commits, branches & tags (now unified as "labels") and repository items (= files and directories). Luckily, the story has come to a good end. Well, "end"? Depends.

Yeah, those were the times. Weekly status updates during the Google Summer of Code... well, I'm too lazy to do that when I'm not forced to :-P
Let's see... the version control api term says that the last status update was in September '07. Way too long ago. So what's up going on in the Version Control API realm at the moment? Lots of good stuff. (Read on! It's just the <!--break-->.)