This site is a static archive of the Aegir community site. Documentation has moved to http://docs.aegirproject.org. Other community resources can be found on the Contacting the community page.
Skip navigation

Revision of Git access to the code from Sun, 10/31/2010 - 05:55

Help

Git access to the code

The Aegir project uses Git as a version control system for managing the project code.

Aegir is also made up of several separate components designed to work together.

Repositories locations

Once upon a time, these components were stored on drupal.org and managed using Drupal's CVS system. Remnants of those projects are still located on drupal.org and for historical purposes, we maintain the Issue queues in their original locations there.

The git repositories are stored on Koumbit's servers.

There is a web interface for your perusal at http://git.aegirproject.org

There are the URLs you can use to pull the repositories:

  • Provision - git clone git://git.aegirproject.org/provision
  • Hostmaster - git://git.aegirproject.org/hostmaster

  • Drush is also available through an unofficial repo: git clone git://git.koumbit.net/drupal/modules/drush. This repository is synced with CVS every thirty minutes.

Developers with push access to the repositories should pull via SSH.

Branch naming convention

  • master is always the main development branch. Think of it as CVS HEAD. When you commit there, you make everyone suffer, so unless you are confident your change needs to be in the mainline, you are likely to want to use feature branches (below).
  • aegir-0.x are stable branch releases, where aegir is the subproject name (e.g. provision-0.4-alpha3, hostmaster-0.4). We don't have that in CVS: they allow us to roll point releases on our production releases. This branch will have tags like aegir-0.x.1, aegir-0.x.2, aegir-0.x.y. Once we hit 1.0, it's exactly the same thing without the 0.: branch is aegir-1 and tags are aegir-1.x. Commits to those branches should be first tested on the master branch (if possible) and then carefully tested there through alpha/beta/rc stages before a new tag is laid.
  • development or "feature" branches must be prefixed with "dev-" and use the issue number (if available or relevant) and a short name. So for example, there could be work on a dev-12345-mybug branch or dev-dns branch for a larger feature (DNS, in that case) which doesn't fit in a single issue.

It is important that this naming convention be followed, particularly for release tags, as the tags are used to generate the tarballs published on http://files.aegirproject.org/. (See this script for details on how this works.) So if a tag named provision-0.4 is pushed, the provision-0.4.tgz file will be generated.

Deprecated and/or merged branches will be moved to an eventual "attic", a clone of the main repository that will keep all dead branches. We will cleanup every major release.

The CVS tags and branches are still accessible in git and will be kept there for posterity. They respect the traditional Drupal.org naming convention.

A crash course in Git

Clone a repo

Let's take provision:

git clone git://git.aegirproject.org/provision

If successful, you will have a provision directory at the last state of development ('HEAD' in CVS speak, 'master' branch in git speak).

Check the status of the local git repository:

git status

See the commit messages:

git log

Check all 'releases'

git tag

Create a new branch for your local development:

git checkout -b <new_branch_name>

Create a new branch for development, based on an existing remote branch

git checkout -b <new_branch_name> origin/<branch_name>

Developing the Aegir project with git

So say you have some work you want to do on the provision module. You first need to clone the repository:

git clone git://git.aegirproject.org/provision

That will create a 'provision' directory with the whole history of the project, and a checkout of the "master" branch (which is the equivalent of CVS's "HEAD" in git).

You make some modifications to the code to fix a bug, and then, you make a commit. That commit will only be local for now, that's the way git works:

vi provision.inc
git commit -m "#12345 fix that pesky bug in provision.inc" provision.inc

Note that contrarily to subversion or CVS, you need to explicitly mention which file(s) you want to commit. You can also use the -a flag to commit all changes.

If you have write access to the repository, you can now push your changes straight into git. However, the git:// url above is readonly, so you will want to use SSH to push your changes. For that, we will have had to add your SSH public key to our repositories. You may also want to add a special "remote" repository to push your changes. You will need to do this only once (per repository):

git remote add aegirproject ssh://gitosis@git.aegirproject.org/provision

You can now push your changes to that repository.

git push aegirproject

If you do not have write access to the repository, you can send me the Aegir developers patches by submitting them for review in as a user that has write access to the repository. Then you need to run this:

Issue queues

The or by email (use the mailing lists), using the following formula:

git-send-email

... or it involves having the origin and master branches synced manually, which doesn't work.

Automatically commiting on push

I'm working on automatically pushing the changes to CVS when pushing to the central repository. The *receive hooks get passed the commits that delimit the commits pushed, and on which branch:

git-format-patches.

Need help?

Documentation

The notebook section provides a way for you to store and share information with your group members. With the book feature you can:

  • Add book pages and organize them hierarchically into different books.
  • Attach files to pages to share them with others.
  • Track changes that others have made and revert changes as necessary.
  • Archive books that are no longer of interest to the group. Archived books can be reactivated later if needed.

The revisions let you track differences between multiple versions of a post.