I have finally got around tackling git-cvsimport. After a little bit of tweaking around, I've been able to import the entire history of the various Aegir projects on Drupal.org in our git repositories. This will enable much easier collaboration and decentalised development.

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.

I'm working on the Git hooks (specifically the 'update' hook right now) and am trying to figure out what sorts of things we would want in a pre-commit (or pre-push, in the case of DVCSs) hook.

What I have now

For now, I have only been checking whether the user attempting to push has an account with the given repository. Combined with the "admin must approve accounts" setting on repositories, this seems good enough to be useful.

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.

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.

Overview

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.

Introduction

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.

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!

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.

When I gained cvs access, I read the drupal book pages on cvs and also merlinofchaos blog, and polled irc drupal-support.

What I came up with was that there are 2 ways of maintaining releases for contributed modules.

1) Always have the latest code in head, and only release a branch when the new version of drupal comes out. For example when working with module and it is for drupal5 the code is found under HEAD, when the module is upgraded for drupal6, create a branch DRUPAL-5 for the drupal5 module.