how to use git with collective (svn)

probably you are wondering why the hack would i use git when dealing with collective (svn). there are lot of reasons. i'll try to explain my working procces and feel free to comment it and even suggest better/different way.

for start you need git. its important that is version 1.6.1 (or above) since new cool options just found place in this release.

1. pulling project out of collective

git svn clone https://svn.plone.org/svn/collective/Products.TinyMCE --trunk=trunk --tags=tags --branches=branches --revision=75010:HEAD

options (see "git svn clone --help" for more):
--trunk: used to define where trunk folder lives
--tags: used to define where tags folder lives
--branches: used to define where branches folder lives
--revision: range of history with revisions that you want to pull

75010 is revision when Products.TinyMCE was first introduced in collective. and because collective is pretty large repository and we dont want to overload it, i really advice you to specifiy --revision. this will also make cloning go faster.

after you are done git created Products.TinyMCE folder with trunk content inside it.

2. commiting to collective and updating from it
now that we have our working git clone we start working and soon and as we work we can commit changes, but this changes wont show up in the collective repo just yet. you could say you have local repo. so commiting works the same way we would normaly do with

cd Products.TinyMCE
echo "# useless code" >> setup.py # we do some changes
git commit # commit localy
... # we work some more
git svn dcommit # finaly we push to collective
... # now new changes are avail. in collective for us to pick them
git svn rebase # works like svn update


3. taging for release
normaly before release you also tag certain revision to some tag.

git svn dcommit # make sure all is commited to collective
git svn tag # tag it


4. stashing ... (your boss will like it)
its a calm monday morning and you just started to work on new feature on project you are working. last weekend deployment was a success. next minute your boss brakes the door because there is some very important bug you need to fix (normaly is not that important, since nobody dies because of my code, but anyway some takes life more serious then me). you have some not commited code laying around and you would quickly need to return to commited version. with git its easy...

git stash # now your uncommited changes are stashed
... # work on that important bug and make your boss happy, commit it, deploy, etc...
git stash apply # and you are back to calm monday morning


5. working with branches
all your branches and tags are pulled into git. lets look them:

git branch -r # list all remote branches
1.1
1.2
stripped
tags/1.0
tags/1.0rc1
tags/1.0rc2
trunk
git branch # list all local branches
* master
git checkout -b fix-strange-1.2-bug 1.2 # we create local branch for fixing strange bug that apeared in 1.2 branch
git branch # * is marking current active branch
* fix-strange-1.2-bug
master
git checkout master # we switch back to master branch
git svn fetch # fetches the updates with out modifying the local working files (which git svn rebase would)

convinced?

there is one drawback when using git with svn. this is external repositories, but more about this next time.