Two KDE SVN Branches and Git

Published Friday April 3rd, 2009
5 Comments on Two KDE SVN Branches and Git
Posted in Git, KDE, KOffice

Last week the KOffice development hit a rather nice milestone; we reached a ReleaseCandidate. As usual this means we create a branch for the KOffice2.0 releases and we open up ‘trunk’ to new features.

With this branch point the 2.0 line of releases is naturally not going to stop being maintained so any fixes we make on trunk should be considered to be also committed on the 2.0 branch. And thats where it gets a bit sticky.
About half the KOffice developers have been using git-svn for some time now and at least I would rather like to continue using git and thus have the powerful git features available for moving patches between trunk and the 2.0 branch. The part that is sticky is that the mapping between git and svn is, and can not be, one to one. And the script does have some features for such situations but they don’t really work on an svn repo of KDEs format and size. Or, in short, you need to have a bit more git knowledge to set it up for our usage.

Goal; I want to have the ability to have 2 svn branches that I can update and commit to. I further want to be able to use git to move patches between them.
Solution; make a second git-svn checkout and use git remotes to let one know about the other.

#I assume you have a ‘koffice’ git-svn tree here already with the trunk version. To avoid any confusion lets rename it;
mv koffice koffice21
#Make a new checkout of the new branch;
git svn clone $KDESVN/branches/koffice/2.0/koffice -r 947933
# Again avoid confusion and make version explicit;
mv koffice koffice20
cd koffice20
#we create a remote
git remote add -f trunk ../koffice21

And thats it; now we can go into koffice20 and do things like
git svn rebase #sync with upstream svn
git fetch trunk #make visible new koffice21 commits
git log trunk/master
git cherry-pick trunk/master #get that commit from 2.1 and put it on 2.0
git svn dcommit

Naturally the normal git-svn-rebase and friends are still available on the koffice21 directory just like before it was renamed.

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Git, KDE, KOffice


Anonymous says:

Be very careful with this set up. git-svn tracks which git commits have been pushed to svn and to which svn branch by using the git-svn-id: line added to git commit messages. If you bring in commits from other svn branches, git-svn will get confused and sometimes will cease to be able to sync with SVN at all. What I’ve had to do is an interactive rebase and amend each commit to remove the git-svn-id: line so that git-svn can proceed. I suppose you could write a script to go back and scrub those lines from the commits.

David says:

Any chance KDE will migrate to git?

n0ha says:

What’s the difference between a setup like this, and multiple branches in a single git repository, each tracking a different SVN branch? What do you get by having two separate git repositories?

Thomas Zander says:

@n0ha the git-svn integration script works using some metadata that it stores in the .git directory. Due to this its only capable of following one svn branch per repository.
Therefore its required to have more than one repository and then we just have to find a way to link them.

I’ve been using this setup a little and while the ‘git fetch’ and multiple ‘git svn rebase’ calls are a bit confusing, it certainly working quite well to smoothly move patches between the two branches. The git features of auto-merging a commit that patch/diff would have failed over still work quite nicely ๐Ÿ™‚

Marc says:

Do you use svn 1.5/svnmerge merge tracking between the branches? That’s our main concern in kdepim so far. You can write a script that removes the git-svn-id’s, and you could create svnmerge props from this. It’s just that git-svn doesn’t give access to svn props, so you end up maintaining the merge tracking manually :/

Commenting closed.

Get started today with Qt Download now