Revision Control Systems

Introduction

versioncontrol* modules is the family of modules that expose to drupal a way to interact with version control systems.

This is an incomplete list of the versioncontrol* modules, but these are the related ones with the git migration:

• Version Control API
• Version Control API -- Git backend
• Version Control / Project Node integration

Please notice that versioncontrol module depends on other modules, so help at that modules would also help:

• DBTNG
• Autoload
• Views
• Views_field_view

I have begun reading documentation for git, because I need to start using a version control system for a site that I am working on. One thing that I haven't run into yet and which makes me nervous is, is there a way to put an existing drupal site into a git system, with a staging area and everything. I kind of understand how to start up a new repository and stuff, but not how to nudge a pre-existing site into one...

Becky

I currently deploy my changes from dev to production using Git. I find Git a priceless tool for managing my codebase and am seeking ways to automate my deployment tasks without writing too many shell scripts involving drush etc. Does anyone use Aegir as a tool to automate git-based deployment ? Please share your experiences

Hello,

I'm wondering how people use Bazaar to manage version control for their Drupal installations?

• Where do you bzr init? If you have root permissions would you put it at /
• What do you use bzr to version control for you? Do you add your whole www directory with Drupal?
• Do you store the branch local or publish it to Launchpad or another server?

Thanks

We all agree that we want some sort of github-like fork/clone to participate in a project with git.
This means, that somehow, we want to be able that, for a given project and a given issue all users which have submitted a ssh key can contribute.

What we haven't decided on is how to do that, there are several ways.

One repository per project, per user

Each user gets a clone of the main repo hosted on d.o where she can do whatever she wants to.

Mercurial (or popularly, hg) is a DVCS written in Python. It is known for its ease of use, without compromising a lot of power.

See parent wiki page Action items for moving Drupal.org off of CVS for more generic information.

<

ul>

Bazaar is DVCS written in Python, known for its very easy setup and good portability across all major operating systems.

See parent wiki page Action items for moving Drupal.org off of CVS for more generic information.

(start writing points already!)

• Bazaar homepage: http://bazaar.canonical.com/en/

• Bazaar is the way to go if Drupal wants to lower barriers to contribution- Git has a steeper learning curve.

• Bazaar might be an easier migration for cvs/svn users
• Bazaar is easy.

Git is an advanced DVCS in C, that was initially written by Linus Torvalds. It is known for its amazing performance and superior flexibility.
For details and starters, see http://git-scm.org

See parent wiki page Action items for moving Drupal.org off of CVS for more generic information.

Tools for the server

• List on kernel wiki
• Gitosis: http://eagain.net/gitweb/?p=gitosis.git

I am currently using git to manage my site-specific projects, e.g. code that lives under /sites in a multisite (single core) scenario.

However, I find myself needing to work on two things that will require a separate repository tracking the Drupal core: 1) one-off core patches, and 2) install profiles.

I have been harboring some growing concerns about the direction of the plugin manager integration proposals for Drupal core almost since their inception, but have not been able to make an informed opinion on the subject until I had properly reviewed the proposed system on a much deeper scale.

While my impressions of the project and the current implementation are fairly negative, I have aimed to frame my criticisms in a positive constructive manner because I believe that the goals of the project are worthwhile, and that for a large section of users this could be a very flexible and usable solution.

Unfortunately a lot of my concerns have been well founded, and I believe that the implementation of this system needs to be taken in a different direction for it to be able to succeed in its goals, while not negatively affecting projects like Aegir, Open Atrium and many other ‘serious developers’.

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.

A good talk this week, with a lot of stuff to say.

• DamZ dropped by to discuss some of the issues and strategies surrounding the eventual migration of drupal.org to the versioncontrol api. Maintaining the existing links could be a challenge, since they are dependent on the particular entries in cvs.module's cid field.

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)

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.

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.

This are just some random ideas about how we could organize drupal core development when/if it would be powered by git.
Every (core) dev can request a personal git repo for drupal development. Here he can push his stuff too, in a special layout.
The branches are named after issues the dev is assigned to. The base for them is the current HEAD (it's left to the dev pulling it in before starting his work!). Then the dev develops his patch. Whenever needed, he pulls the current HEAD in. When he's done with his patch, he uses a special tag name, and the magic starts: