Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

User:Gerard Caulfield/Fast Moodle git setup: Difference between revisions

From MoodleDocs
No edit summary
No edit summary
(17 intermediate revisions by the same user not shown)
Line 1: Line 1:
This setup allows you to have multiple working directories while having them all linked and using the same repository which I believe is perfect for Moodle development where you sometimes want to view several versions of moodle at the same time but managing all those instances seperatly is an unnecessary hassle.
[[Category:Git]]
 
This setup allows you to have multiple working directories while having them all linked and using the same repository which I believe is perfect for Moodle development where you sometimes want to view several versions of moodle at the same time but managing all those instances seperatly is an unnecessary hassle. I've also tried to minimise the amound of time you have to spend waiting for tasks to complete.
 
==Initial setup==


First create all the necessary directories:
First create all the necessary directories:
<code bash>
<code bash>
# Data directories
# Data directories
mkdir -p ~/data/moodle/int/m/ ~/data/moodle/int/22/ ~/data/moodle/int/21/ ~/data/moodle/int/20/ ~/data/moodle/int/19/ \
mkdir -p ~/data/moodle/int/ ~/data/moodle/pro/
~/data/moodle/pro/m/ ~/data/moodle/pro/22/ ~/data/moodle/pro/21/ ~/data/moodle/pro/20/ ~/data/moodle/pro/19/


# Code directories
# Code directories
mkdir -p ~/src/moodle/int/m/ ~/src/moodle/int/22/ ~/src/moodle/int/21/ ~/src/moodle/int/20/ ~/src/moodle/int/19/ \
mkdir -p ~/src/moodle/int/ ~/src/moodle/pro/
~/src/moodle/pro/m/ ~/src/moodle/pro/22/ ~/src/moodle/pro/21/ ~/src/moodle/pro/20/ ~/src/moodle/pro/19/


# The seed directory
# The seed directory
Line 48: Line 50:
git remote add local /media/myUsbDrive/prettyOldMoodleRepository/
git remote add local /media/myUsbDrive/prettyOldMoodleRepository/
git fetch local
git fetch local
git remote rm local
</code>
<code>
If you did the step above first then git will not need to download any commit objects it already has and so the entire process will go a lot quicker. Fetch everything from the r_int and r_pro repositories. Don't try doing both at the same time as they mostly contain the same data so it may end up trying to download the same thing twice (although I haven't checked).  
If you did the step above first then git will not need to download any commit objects it already has and so the entire process will go a lot quicker. Fetch everything from the r_int and r_pro repositories. Don't try doing both at the same time as they mostly contain the same data so it may end up trying to download the same thing twice (although I haven't checked).  
<code bash>
<code bash>
Line 55: Line 56:
git fetch r_pro
git fetch r_pro
</code>
</code>
==The magic part==
Clone some repositories which will help us setup our linked working directories
<code bash>
cd ~/src
git clone git://github.com/gerrywastaken/git-new-workdir.git
git clone git://github.com/gerrywastaken/MoodeeScripts.git
</code>
Now, from this point, if you have done everything as instructed you should be able to setup your working directories by running one script
<code bash>
~/src/MoodeeScripts/setupWorkingDirs.sh
</code>
==Usage==
Now if you go into any of the directories under '''~/src/moodle/''' each of the working directories will be set to the appropriate version of Moodle and all working directories will be linked to the same '''~/src/moodle/.seed''' repository. These have been created as headless branches so as not to pollute your list of branches with entries like '''MOODLE_22_STABLE''' which will only end up out of date. If you wish to create a new branch or rebase an existing on to a remote branch, it is best to do so directly by first doing a fetch of the remote and then refering to the remote branch using the the following syntax '''<remoteName>/<branchName>'''. Here is an example:
<code bash>
cd ~/src/moodle/pro/22
git fetch r_pro
# Checkout a new branch based on r_pro/MOODLE_22_STABLE
git checkout -b 22_MDL-946136_change_database_activity_to_use_mongodb r_pro/MOODLE_22_STABLE
# Rebase your current branch to r_pro/MOODLE_22_STABLE
git rebase -i r_pro/MOODLE_22_STABLE
# Checkout a headless branch for testing r_pro/MOODLE_22_STABLE
git checkout r_pro/MOODLE_22_STABLE
# Take a look at the last commit to r_pro/master
git log r_pro/master -n1
</code>
If you add a branch, remote or commit while in one working directory it will be available to use from all other working directories so you no longer need to repeat yourself as much as if they were all seperate repositories. This means that if you make a change in your master working directory master you can view it from your 2.2 working directory and cherrypick it back by providing the commit ID without needing to do anything else first such as pulling or pushing. There are other scripts in the ~/src/MoodeeScripts which should give you an idea of the ways in which this shared repository setup has advantages over split repositories. It was my intent to polish these scripts up for general consumption, but I ran out of time.
From this point you still need to install each version of Moodle, but that process is well described in many other places.
==Optional==
To make your setup even easier to use you can install zsh and the oh-my-zsh scripts. (Instructious for a ubuntu/debian system)
<code bash>
sudo apt-get install zsh
chsh -s /bin/zsh
git clone git://github.com/gerrywastaken/oh-my-zsh.git ~/.oh-my-zsh
cd ~/.oh-my-zsh
git checkout moodle
</code>
Backup your zsh config file and overwrite it with the .oh_my_zsh template and then reload the zsh config
<code bash>
cp ~/.zshrc ~/.zshrc.orig
cp ~/.oh-my-zsh/templates/zshrc.zsh-template ~/.zshrc
source ~/.zshrc
</code>
The screenshot below shows how we would go about checking out a new branch named m_MDL-007_eliminate_bad_guys based on production master (r_pro/master). You will also notice that the current branch is shown on the right hand side (note: headless branches are not displayed, it was something I hoped to address but ran out of time). I then create a file called testfile.txt so you can see the marker which appears if your current banch has uncommited changes. Switching from pro/22 to int/22 is then demonstrated followed by an illustration of one of the advantages of enabling color in git.
[[Image:showingOhMyZsh.png|frame|center|Showing some of the various advantaes of using oh-my-zsh for moodle development]]

Revision as of 09:39, 27 February 2012


This setup allows you to have multiple working directories while having them all linked and using the same repository which I believe is perfect for Moodle development where you sometimes want to view several versions of moodle at the same time but managing all those instances seperatly is an unnecessary hassle. I've also tried to minimise the amound of time you have to spend waiting for tasks to complete.

Initial setup

First create all the necessary directories:

  1. Data directories

mkdir -p ~/data/moodle/int/ ~/data/moodle/pro/

  1. Code directories

mkdir -p ~/src/moodle/int/ ~/src/moodle/pro/

  1. The seed directory

mkdir ~/src/moodle/.seed/

Create a symbolic link in your web root so you can access all of these directories via http://localhost/moodle/ (or whatever location you prefer) sudo ln -s ~/src/moodle /var/www/moodle

Create the .seed repository for all the other working directories: cd ~/src/moodle/.seed/ git init Turn on colorisation and ignore file permission changes git config core.ui auto git config core.filemode false Set yourself as the default author of commits to the repository (you will need to replace the name and email used in the following two example commands) git config user.name 'John Doe' git config user.email johndoe@example.com Add Moodle remotes for Integration and Production (fyi: some people refer to production as "stable", but the word stable is used in integration branche names, so I think production is a better term for this remote). I have added "r_" to the front of the remote names so that there is no ambiguity. Without this in some instances git will not be able to tell if we mean the remote "int" or the folder "int". For the production repository we have used the name "moodle.git", instead of describing it's use case like we did for "integration.git". I can't be sure but I imagine this is done for sites like github, where the repository name is how people find your project, so labeling the repository "production.git" would have make it difficult for people to locate the repository in a search. However I suggest while working on it you think of it as the production repository instead of the moodle repository to keep thing consistent and it's purpose clear. git remote add r_pro git://git.moodle.org/moodle.git git remote add r_int git://git.moodle.org/integration.git If you have a github account you will probably also wish to add a remote for that so you can push changes to it as a public storage location for your changes that you can then link to in Moodle tracker issues. First you need to fork the moodle repository on github. After doing that you can add a remote to it as shown below, remembering to replace yourGithubUsername with your actual github username git remote add yourGithubUsername git@github.com:yourGithubUsername/moodle.git If you have a repository that is local to you which contains a copy of moodle you can fetch from that first. The more recent it is the better. git remote add local /media/myUsbDrive/prettyOldMoodleRepository/ git fetch local If you did the step above first then git will not need to download any commit objects it already has and so the entire process will go a lot quicker. Fetch everything from the r_int and r_pro repositories. Don't try doing both at the same time as they mostly contain the same data so it may end up trying to download the same thing twice (although I haven't checked). git fetch r_int git fetch r_pro

The magic part

Clone some repositories which will help us setup our linked working directories cd ~/src git clone git://github.com/gerrywastaken/git-new-workdir.git git clone git://github.com/gerrywastaken/MoodeeScripts.git Now, from this point, if you have done everything as instructed you should be able to setup your working directories by running one script ~/src/MoodeeScripts/setupWorkingDirs.sh

Usage

Now if you go into any of the directories under ~/src/moodle/ each of the working directories will be set to the appropriate version of Moodle and all working directories will be linked to the same ~/src/moodle/.seed repository. These have been created as headless branches so as not to pollute your list of branches with entries like MOODLE_22_STABLE which will only end up out of date. If you wish to create a new branch or rebase an existing on to a remote branch, it is best to do so directly by first doing a fetch of the remote and then refering to the remote branch using the the following syntax <remoteName>/<branchName>. Here is an example: cd ~/src/moodle/pro/22 git fetch r_pro

  1. Checkout a new branch based on r_pro/MOODLE_22_STABLE

git checkout -b 22_MDL-946136_change_database_activity_to_use_mongodb r_pro/MOODLE_22_STABLE

  1. Rebase your current branch to r_pro/MOODLE_22_STABLE

git rebase -i r_pro/MOODLE_22_STABLE

  1. Checkout a headless branch for testing r_pro/MOODLE_22_STABLE

git checkout r_pro/MOODLE_22_STABLE

  1. Take a look at the last commit to r_pro/master

git log r_pro/master -n1

If you add a branch, remote or commit while in one working directory it will be available to use from all other working directories so you no longer need to repeat yourself as much as if they were all seperate repositories. This means that if you make a change in your master working directory master you can view it from your 2.2 working directory and cherrypick it back by providing the commit ID without needing to do anything else first such as pulling or pushing. There are other scripts in the ~/src/MoodeeScripts which should give you an idea of the ways in which this shared repository setup has advantages over split repositories. It was my intent to polish these scripts up for general consumption, but I ran out of time.

From this point you still need to install each version of Moodle, but that process is well described in many other places.

Optional

To make your setup even easier to use you can install zsh and the oh-my-zsh scripts. (Instructious for a ubuntu/debian system) sudo apt-get install zsh chsh -s /bin/zsh git clone git://github.com/gerrywastaken/oh-my-zsh.git ~/.oh-my-zsh cd ~/.oh-my-zsh git checkout moodle

Backup your zsh config file and overwrite it with the .oh_my_zsh template and then reload the zsh config cp ~/.zshrc ~/.zshrc.orig cp ~/.oh-my-zsh/templates/zshrc.zsh-template ~/.zshrc source ~/.zshrc

The screenshot below shows how we would go about checking out a new branch named m_MDL-007_eliminate_bad_guys based on production master (r_pro/master). You will also notice that the current branch is shown on the right hand side (note: headless branches are not displayed, it was something I hoped to address but ran out of time). I then create a file called testfile.txt so you can see the marker which appears if your current banch has uncommited changes. Switching from pro/22 to int/22 is then demonstrated followed by an illustration of one of the advantages of enabling color in git.

Showing some of the various advantaes of using oh-my-zsh for moodle development