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.
