In the town called Workflow, lived three friends - Git, CVS and Drupal

Written by Arvinder Singh / March 07, 2009 / 5 mins read / Filed under Public-private-keys, / Git, / Cvs

Moving ahead on the new project, I decided to install a versioning system. I kinda have a crush on Git, however have not been using it regularly. So what better time to rekindle the old fire?

I have used SVN in the past, however CVS is still the old faithful dog hosting Drupal repositories. I wanted to concentrate on using Git, while wanted easy way to update drupal installations.

After a number of blog reads, here is my workflow (at-least the planned workflow)

Lets start by freeing ourselves from typing in password each time and allowing only public-private key authorization.

Password free remote Login

Following is more or less a shameless rip from this article (Here for my own reference).

On my local machine, I already had generated ssh key-pair. However in the ~/.ssh/ folder I found id_dsa, id_dsa.pub pair along with id_rsa, id_rsa.pub pair. Hmmm! A little digging into the man pages revealed the difference between RSA and DSA.

$ man ssh-keygen

RSA uses 2048 for encryption by default and can vary, while DSA used exactly 1024.

Lets copy our public key to the server.

$ scp ~/.ssh/id_rsa.pub myusername@myserver:~/

On my remote server

$ mkdir ~/.ssh
$ cat id_rsa.pub >> ~/.ssh/authorized_keys
$ rm id_rsa.pub

Lets activate the key

$ sudo su -
# vi /etc/ssh/sshd_config

Edit the file ensure following options

RSAAuthentication yes
PubkeyAuthentication yes

Save and quit vim. Relaod the configuration.

$ sudo /etc/init.d/ssh reload

Now if we access the server from my client machine, it does not asks for a password.

Lets disable authentication by password, to shield brute-force attempts.

$ sudo vi /etc/ssh/sshd_config

Edit the file ensure following options

....
ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no
...

and reload SSH configuration file:

$ sudo /etc/init.d/ssh reload

Thats it. A machine with a differnt private key would not be able to log in.

I also thought of making my official GnuPG/PGP Encryption key and putting it up on the website. But thats for another day.

Back to our main topic - Git-svn workflow

On my local machine

$ mkdir -p ~/src
$ cd src
$ cvs -z9 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal checkout -r DRUPAL-6 drupal
$ cd drupal
$ git init
$ git add .
$ git commit -m  "The inital commit of drupal6 core presently at version 6.10"

Now lets login to server, where we want to host the git repository for redundancy.

$ ssh myusername@myserver
$ mkdir -p ~/gitReps/drupal.git && cd  ~/gitReps/drupal.git
$ git --bare init
$ exit

Back on our client machine

$ git remote

Nothing returns. Good we are on right track.

$ cat .git/config

Returns

[core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true

Lets add remote repository.

git remote add myTux ssh://myusername@myserver/home/myusername/gitReps/drupal.git

Now above command will return

[core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
[remote "myTux"]
	url = ssh://myusername@myserver/home/myusername/gitReps/drupal.git
	fetch = refs/heads/*:refs/remotes/myTux/*

Running git branch shows just one branch locally

* master

Lets push this to our remote server

$ git push myTux master
Counting objects: 703, done.
Compressing objects: 100% (636/636), done.
Writing objects: 100% (703/703), 1.13 MiB | 1600 KiB/s, done.
Total 703 (delta 29), reused 0 (delta 0)
To ssh://myusername@myserver/home/myusername/gitReps/drupal.git
 * [new branch]      master -> master

That is our first drupal repository. It would only carry drupal bare-bone code. Any update to drupal-core will be applied here as follows.

Clone the drupal on local machine and update from drupal using cvs. Then update the git and push the changes to remote server.

$ git clone ssh://myusername@myserver/home/myusername/gitReps/drupal.git
$ cd drupal.git
$ cvs update -r DRUPAL-6.11 -dP
$ git status
$ git add .
$ git commit -m "Drupal core updated to version 6.11"
$ git push myTux master

Now lets create two other seperate clone of this repository. drupal-and-modules.git would keep updates repository along with updated modules and themese. drupal-production.git would keep code ready to be deployed. (I was wondering if some workaround with using branches can solve it? Any suggestions?)

On the server

$ git clone drupal.git drupal-and-modules.git

On client machine

$ git clone ssh://myusername@myserver/home/myusername/gitReps/drupal-and-modules.git
$ mkdir sites/all/modules
$ cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -d sites/all/modules/cck -r DRUPAL-6--2-1 contributions/modules/cck
$ git add .
$ git commit -m "Imported cck 6-2.1 imported"

Now lets push this changed drupal to drupal-and-modules.git on remote server.

$ git remote
origin
$ git branch
* master
$ git push origin master
Counting objects: 343, done.
Compressing objects: 100% (306/306), done.
Writing objects: 100% (336/336), 375.90 KiB, done.
Total 336 (delta 37), reused 0 (delta 0)
To ssh://myusername@myserver/home/myusername/gitReps/drupal-and-modules.git
   046640c..dc5c0c3  master -> master

This updates the drupal-and-modules.git.

When drupal.git is updated, drupal-and-modules.git can be updated simply by using command

git pull

Similarly we can maintain a third repository with all the localization and ready for production.

The implementation worked fine and the workflow should work in theory. However I’m pretty sure, it will be polished as I use git more and start using rebasing and stashing.