the fancy part of the web

TemplaVoila on github.com

Update: Finally TemplaVoila moved to git.typo3.org – please read the update here

As it seems, souce code version control for TYPO3 will be done with Git in the future. The Phoenix team already uses git.typo3.org, there’s also already the possibility to get the latest updates for the v4 Core via github.com and it won’t take long until git.typo3.org is been used for version 4 as well.

Due to the fact that my TemplaVoila development workflow is also already git based, I thought it might be interesting for some contributors to develop with a git repository upstream. Therefore I started to maintain a TemplaVoila repository on github.com [1]. The Subversion repository on forge.typo3.org [2] is of course still the master, but both repositories are kept in sync automatically.

So once you think about sending an RFC to the typo3.team.templavoila list, feel free to attach a git based patch-file.

[1] http://github.com/tolleiv/TemplaVoila
[2] https://svn.typo3.org/TYPO3v4/Extensions/templavoila/

Update: Finally TemplaVoila moved to git.typo3.org – please read the update here As it seems, souce code version control for TYPO3 will be done with Git in the future. The...

T3DD10 Git workshop

I just found that Peter shares the slides of the Git workshop from the T3DD10 on slideshare. Since this 4 hour workshop was – for many reasons – one of my favorites during the T3DD10, I felt that it’s worth to mention it. And due to the fact that TYPO3 is moving very fast towards Git it’s worth to look at them — Open workshop slides

Btw. at the beginning I didn’t belief that a Git workshop could fill 4 hours – now I don’t think that shorter workshops make any sense

I just found that Peter shares the slides of the Git workshop from the T3DD10 on slideshare. Since this 4 hour workshop was – for many reasons – one of...

Using git svn for TYPO3 extension development

When I first saw a presentation about Git 2 years ago I liked it, but I was convinced that Subversion covers all I need. Things have changed and especially the bad performance of Subversion for larger repositories and the need to commit things without messing up the official trunk motivated me to look up how to get started with Git. If you need more reasons why you should look into Git, you’ll find them in [7] – anyways it’s worth to have a look how I managed to work with it

There are basically 2½ different tasks during the “daily” development.

0. Create a local working copy a.k.a clone the repository
1. Fix a bug or implement a feature and create a patch file with the changes
2. Receive a patch and review it – eventually commit the changes

0. Repository initialization

Getting started and creating the repository from an existing Subversion repository looks like this:

mkdir templavoila
cd templavoila
git svn init -t tags -b branches -T trunk https://svn.typo3.org/TYPO3v4/Extensions/templavoila
git-svn fetch

This will pull the entire SVN history into your local Git repository – use “git-svn fetch -r ” to reduce the amount of imported revisions.

To keep your repository up-to-date you need these commands:

git stash
git-svn fetch
git rebase trunk
git stash apply

If you followed the SVN trunk/tags/branches convention you should see that it also finds tags and branches during the import. But using “git branch” afterwards you’ll see that there’s only one local branch called “master”. That’s where Git shows it’s strength the first time, because it distinguishes between local and remote branches. Work can only be done within local branches, whereas the existing SVN branches are only recognized as “remote” branches so far. To list all remote branches you can use “git branch -r”. If you followed the trunk/tags/branches convention, you should see your SVN tags and branches within this list – otherwise you might want to read [8]. To make a remote (SVN) branch available in your local repository use:

git checkout --track -b tv_1-4 templavoila_1-4

1. Working with the repository

Starting to work on a new feature or a bug always starts with a new branch in git:

git branch issue00012345
git checkout issue00012345

You’re now working in the “issue00012345″ branch and all commits will just be committed to that branch. Once you made changes you can either just commit all modifications with:

git commit -a

or add particular files and commit only these files with:

git add fileA
git add fileB
git commit

or with a nice pre commit preview which lets you decide which lines you want to commit:

git add --patch
git commit

Preparing the patch for the mailingslist:
In a pure Git workflow “git format-patch” is used to communicate patches, but due to the fact that there’s a Subversion repository involved either the old style diff / patch or a workaround needs to be used to communicate changes.
Creating a patch which works for the mailinglist can basically be done using:

git diff --no-prefix master > myPatchFile.patch

An alternative workaround to create proper SVN diff files (including svn revision etc..) can be found in [10] it’s used very straight forward:

git svn-diff > mySvnPatchFile.patch

2. Review and commit patches

Reviewing the patch someone sent to the list:
As “usual”

patch -p0 < myPatchFile.patch

can be used to apply patch files.

Once the files passed the review the changes can be committed using “git add” and “git commit” as shown before.

Committing to Subversion:
Once you committed everything to your local repository you’re able to perform this command to “forward” your commits to the Subversion repository.

git svn dcommit

Practically every single commit within git will also be reflected as a single Subversion commit. For several reason this might not always suit your situation.As a workaround you could merge all commits during the merge of your feature branches into the master branch using:

git merge --commit --squash issue00012345
git svn dcommit

Of course I don’t recommend to do this for your regular work since have small granular commits is always better.

Sources and further reading

[1] Patch-oriented development made sane with git-svn
[2] An introduction to git-svn for Subversion/SVK users and deserters
[3] Git – SVN Crash Course
[4] Getting the GIT checkout
[5] An Illustrated Guide to Git on Windows
[6] git svn workflow –
feature branches and merge
[7] whygitisbetterthanx.com
[8] Multiple branches using git-svn
[9] Effectively using Git with subversion
[10] Git Workflow with Upstream SVN

Notes

• Don’t try to dcommit to https://svn.typo3.org/TYPO3v4/Extensions/templavoila unless you know what you’re doing – I just used it to show you that it’s even working with large history projects.
• For projects hosted on forge.typo3.org there might be a native git support soon – stay tuned
• Let me know if you had problems with any of the snippets
• Further information about the review process for the TYPO3 Core and several other TYPO3 related projects can be found on typo3.org

When I first saw a presentation about Git 2 years ago I liked it, but I was convinced that Subversion covers all I need. Things have changed and especially the...