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

Jump to: navigation, search
 
(23 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 22: Line 24:
 
Create the .seed repository for all the other working directories:
 
Create the .seed repository for all the other working directories:
 
<code bash>
 
<code bash>
cd ~/src/.seed/
+
cd ~/src/moodle/.seed/
 +
git init
 +
</code>
 +
Turn on colorisation and ignore file permission changes
 +
<code bash>
 +
git config core.ui auto
 +
git config core.filemode false
 +
</code>
 +
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)
 +
<code bash>
 +
git config user.name 'John Doe'
 +
git config user.email johndoe@example.com
 +
</code>
 +
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.
 +
<code bash>
 +
git remote add r_pro git://git.moodle.org/moodle.git
 +
git remote add r_int git://git.moodle.org/integration.git
 +
</code>
 +
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 [https://github.com/moodle/moodle github]. After doing that you can add a remote to it as shown below, remembering to replace yourGithubUsername with your actual github username
 +
<code bash>
 +
git remote add yourGithubUsername git@github.com:yourGithubUsername/moodle.git
 +
</code>
 +
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.
 +
<code bash>
 +
git remote add local /media/myUsbDrive/prettyOldMoodleRepository/
 +
git fetch local
 +
</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).
 +
<code bash>
 +
git fetch r_int
 +
git fetch r_pro
 +
</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>
 
</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]]

Latest 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:

# Data directories
mkdir -p ~/data/moodle/int/ ~/data/moodle/pro/
 
# Code directories
mkdir -p ~/src/moodle/int/ ~/src/moodle/pro/
 
# 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
# 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

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