Managing - from CVS-in-Svn to Git

Hi there, and welcome to the first of my bi-annual blog entries. ;)

Today, ladies and you oh so gentle men, we'll be looking at something very exciting, something very hip, something so edgy it could be called bleeding. Yes. We're talking Git. We're talking a new VCS paradigm. We're talking Drupal, and we're talking managing Drupal sites.

First and foremost, this is the tale of how I set up to have its code managed by Git.

The prequel

In yon olden days, was managed by CVS checkouts. These CVS checkouts were then added to a Subversion repository that'd keep track of them all. This meant that everytime I cvs up'ed, I would have to manually svn rm and svn add gone and new files. It also meant that there had to be a source repos somewhere, that I would have to have access to at all times where I wanted to work on the site.

This wasn't something that I found very fluid nor easy to work with. At this point, I had already been looking at Git to replace Subversion for a while, but never gotten around to it. Subversion was familiar and something I have worked with before, Git was uncharted territory. Not only a new system, but a completely new way to handle versioning.

Here comes TGGM!

The Drupal community has also been unsatisifed with CVS for quite some time, and what should eventually be the replacement of it had been the subjection for discussion. And more discussion. And the discussion was discussed. And then some new discussion. The result? It finally landed on Git! Yes, all the code in's CVS repository are now, as we speak (or I write, you read), available in Git repositories!

So, to stay on the edge, I decided to go ahead and move to be managed by Git on the very same day of this change. Here's what I did.

The procedure

Warning! Remember to back up your site before trying to do any of this at home, kids! Also beware of losing translation files, local changes, etc. cvs diff is your friend.

Setting it up

I keep the files of my site locally and push them to the server when they're updated, so let's start by moving the old directory aside.
# www> mv
Now we need a new directory to keep the files in. But hey, this directory is the repository! So let's clone Drupal core:
# www> git clone --branch 6.x freso\.dk
I now have a new directory "" containing a check-out of the branch "6.x" from Drupal's Git repos. I don't want to mess around with the core though, so to keep this pristine, let's make some new branches for running the site:
# www> cd
#> git branch -t 6.x+contrib 6.x
#> git branch -t 6.x+contrib

Now there are three branches I need to worry about: 6.x, which is Drupal's core; 6.x+contrib, which additionally has various contrib modules etc. on top of it; and which will also have certain site specific changes (e.g., to .htaccess etc.).

Adding modules from CVS site

Let's populate the contrib branch:
#> git checkout 6.x+contrib
#> ../

First the branch is being checked out, then I run a little script of mine. It basically runs through the old dir's sites/all and runs git submodule add for each project it finds. (Feel free to expand on it, the code's in my (Git) sandbox and patches are accepted.)

Alright, so the site is now populated with modules. But what version? All the modules have been submodule add'ed to their master branch, so here's a bit of a manual part. I went to admin/reports/updates and went through the list, using git checkout to the currently installed version on all the module folders. Then I finished off by git commit -a in the root folder. Be sure that all of your installed/enabled modules are on a useable version, it might cause trouble if you, for example, have a 7.x module on a 6.x site...

Adding module: Git Deploy

Before I go on with the site specific changes, let's add one module first: Git deploy. It doesn't have any releases, so I'm living on the edge and adding the -dev version:
#> git submodule add --branch 6.x-1.x sites/all/modules/git_deploy
#> git commit -a -m "Added git_deploy module at 6.x-1.x."

Site specific files

Now, let's look at some of the site specific stuff.
#> git checkout
#> git pull

After copying over changed and site specific files (.htaccess, robots.txt, settings.php, etc.) from the old directory and committed these, we're now almost there! First, let me comment on the settings.php. Don't store your password in the VCS. Not unless you're sure that nobody else will ever have access to it. I've simply removed the $db_url = '...' line and replaced it with require_once('db_url.php'). "db_url.php" then simply contains the $db_url line, while also being mentioned in the .gitignore (which also has an entry for files/). That way I can track settings.php without worrying about my database password accidentally slipping out, should I ever share access to the repos with anybody. :)

Final touches

Now, once you've double and triple checked that all the files you want (and need!) are there, upload it all to your server, removing old CVS and Svn cruft, and head straight for admin/build/modules - disabling CVS Deploy, enabling Git Deploy. (Notice that for 6.x, Git Deploy requires the Libraries module for discovery of the Glip 3rd party library - which it also requires.) (Also, at this point my theme, Garland with color, decided to stop working, the solution was to fiddle with the colour wheel and so it reset.)

After you've switched the deploy modules, let's go back to the terminal to remove CVS Deploy. Unfortunately, there's no "git submodule rm", so we need to hack a bit:
#> git checkout 6.x+contrib
#> sed --in-place '/cvs_deploy/d' .gitmodules
#> sed --in-place '/cvs_deploy/d' .git/config
#> git rm --cached sites/all/modules/cvs_deploy
#> git commit -a
#> rm -rf sites/all/modules/cvs_deploy

The sed commands delete the lines containing "cvs_deploy", with the "--in-place" option telling sed to work directly on the file, instead of printing to stdout.

Once all that is done.. we're ready to test the site. Once the testing's satisfactory, let's upload the files to the server and enjoy the new workflow. :D

ps. Remember to Google/search for any thing you might want to do with Git. A lot of people have written a lot of easily digestable materials on how to use it - don't let their work be for naught! :)


Yes, I was also wondering the

Yes, I was also wondering the same thing as Jens. Any new design at some point?

Thomas - tandlæge København

Are you considering a new

Are you considering a new design at some point?



Indsend kommentar

Indholdet af dette felt er privat og bliver ikke vist offentligt.
  • Web- og e-mail-adresser omdannes automatisk til links.
  • Tilladte HTML tags: <q> <blockquote> <cite> <abbr> <a> <ins> <del> <strong> <em> <hr> <address> <code> <dfn> <kbd> <pre> <samp> <var> <h2> <h3> <h4> <h5> <h6> <dl> <dt> <dd> <ol> <ul> <li> <caption> <col> <colgroup> <table> <tbody> <td> <tfoot> <th> <thead> <tr> <bdo> <ruby>
  • Linjer og afsnit ombrydes automatisk.
  • Indsæt Flickr billeder: [flickr-photo:id=230452326,size=s] eller [flickr-photoset:id=72157594262419167,size=m].
Ved at indsende denne formular, accepterer du Molloms privatlivspolitik.