So we have switched to using Git to work on aegir.
The git repositories are stored on Koumbit's servers. There are the URLs you can use to pull the repositories:
- provision -
- hostmaster -
- drush is also available through an unofficial repo:
git://git.koumbit.net/drupal/contrib/modules/drushThis repository is synced with CVS every thirty minutes.
There is also a web interface for your perusal at http://git.aegirproject.org/
Repositories are also accessible through SSH, although that's recommended only for developers that have push access. See the web interface above for the URLs.
Branch naming convention
masteris always the main development branch. Think of it as CVS
HEAD. When you commit there, you make everyone suffer, so you are likely to wan to use feature branches (below).
aegir-0.xare stable branch releases, where
aegiris the subproject name (e.g.
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-1and 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-dnsbranch 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 traditionnal Drupal.org naming convention.
These old instructions do not apply anymore: all of the Aegir code is now hosted in git and not synced to CVS anymore. This documentation is kept in case we need to maintain third party CVS modules (like drush, for example).
Get a clone of the cvs for one module
Sometimes you want to fetch a module and to create a local 'git-clone'.
you need git and git-cvsimport
in a directory you want to store modules like ~/dev/git-contrib
on_your_command_line: git cvsimport -v -d :pserver:email@example.com:/cvs/drupal-contrib -C module_directory contributions/modules/module_directory
e.g. to fetch the module amplify
git cvsimport -v -d :pserver:firstname.lastname@example.org:/cvs/drupal-contrib -C amplify contributions/modules/amplify
Use the same command to update your local git-repository.
git cvsimport creates on your computer the directory for the modul (amplify) and the git repository (amplify/.git)
.git is a hidden directory.
in a unix - Environment use ls -la to see the .git directory.
This is a way to fetch all modules (timeconsuming), but for some modules this does not work, since git cvsimport throws an error (for different reasons).
If successful, you will find in the modules directory (git working dir) the last state of development (Head).
Check the status of the local git repository:
see the commit messages:
check all 'releases'
create a new branch for your local development:
git checkout -b
Committing and sharing changes
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.koumbit.net/drupal/modules/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:
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, you will first need to add a special "remote" repository to push your changes. You will need to do this only once (per repository):
git remote add koumbit git.koumbit.net:/srv/git/drupal/modules/provision
You can now push your changes to that repository.
git push koumbit
If you do not have write access to the repository, you can send me the patches by email (contact me through the contact form first) using git-send-email or git-format-patches.
Pushing changes to CVS
Now pushing to koumbit above does not yet commit to CVS. We would like to fix that, but it would probably involve hosting the repositories directly on Drupal.org with access to the CVS repository.
To commit to CVS, you need to already have a checkout of the CVS repository, logged in as a user that has write access to the repository. Then you need to run this:
git-cvsexportcommit -c -p -v -w /home/anarcat/dist/provision.cvs/ <COMMIT-ID>
The trick is to find the commit id. I have been able to sync a bunch of commits at a time using the following formula:
git-cherry origin master | sed -n 's/^+ //p' | xargs -l1 git-cvsexportcommit -c -p -v -w /home/anarcat/dist/provision.cvs/
... but 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:
e402d8011e3e857cc2ed718246c3cfe8bfcaf045 06b337116329d0972b9bf11c0f0f07c624606285 refs/heads/master
refs/heads/master part shows which branch we're on and can be used to decide where to push in CVS (HEAD/DRUPAL-N...). (In fact the git-cherry syntax is more like:
That is all we need to commit it all. We can use git-log to figure out the exact list of commits we want to push out:
$ git log --pretty=format:%H e402d8011e3e857cc2ed718246c3cfe8bfcaf045..06b337116329d0972b9bf11c0f0f07c624606285
Now the only thing missing is the permissions issues.
BM: Based off some of the work here, using it to add on to the approach in the Drupal.org handbook, Agaric was able to create a (single-user, for now) script to automate pushing Git commits to CVS. Review/refinements greatly appreciated.