Since git is my vcs tool of choice, I’m trying very hard to avoid using svn but in my work, it’s often a requirement to create branches and tags in subversion off a specific revision instead of randomly assuming that the current trunk is the revision that QA wants. It’s annoying to have to switch from git over to subversion on a remote server to handle this one task but there hasn’t been a process described for me on how to accomplish this. I’ve found that the git-svn branch mechanism is a little lacking in the area and couldn’t find anything regarding documentation or tutorials on how to do this
The goal: Pick a revision and base a branch or tag on it.
This process should work but I’m still testing it out so be forewarned and always use -n or –dry-run when running commands that might affect the svn repo.
To see the current revision that master points to
git svn info
Dry run the branch creation to see what it’s going to do.
$> git svn branch -n -m"test branch via git-svn" TEST_BR_01
Copying svn://subversion/data/foo/trunk at r17089 to svn://subversion/data/foo/branches/TEST_BR_01...
You can add “-t” to make that a tag instead. Usually, my process when creating release branches is to create a pre-release tag
and then based the branch off that tag. It’s not quite as simple with git-svn and we’re just going to have to focus on the revision number for correlation.
To force the branch creation at a specific revision, we have to reset the master to point to the revision we want.
To get the correct revision, we check git svn log and look for the appropriate commit it.
$> git svn log
commit a7b9cf2d8c9d7d1621739d441b8f77927b5a8c90
Author: mmullis
Date: Wed Apr 14 00:32:45 2010 +0000
refactor: eliminate duplicate code
git-svn-id: svn://subversion/data/foo/trunk@17089 22e23496-6b6f-0410-a477-83c9a211b16a
…….
commit 29ff96bc08869dd1770ccea3e68ffec2689d9483
Author: mmullis
Date: Wed Apr 14 00:32:03 2010 +0000
drop support for unused features
git-svn-id: svn://subversion/data/foo/trunk@17085 22e23496-6b6f-0410-a477-83c
What QA asked for was to wait on the refactoring so we’re going to base the release on
commit “29ff96bc08869dd1770ccea3e68ffec2689d9483″.
Now for the tricky part which took me a good while to figure out – no help from google.
We’re going to reset master to point to a different commit point.
$> git reset --hard 29ff96bc08869dd1770ccea3e68ffec2689d9483
HEAD is now at 29ff96b drop support for unused features
With that in place, let’s test the branch create again.
$> git svn branch -n -m"test branch via git-svn" TEST_BR_01
Copying svn://subversion/data/foo/trunk at r17085 to svn://subversion/data/foo/branches/TEST_BR_01...
Notice that it’s using r17085 instead of the previous r17089.
Now I can run for real by dropping the -n and we’ll have a new branch created at a specific revision point.
Don’t forget to reset the master back to remotes/trunk or you’ll screw yourself up pretty good.
This one is easy and doesn’t need the commit id.
$> git reset --hard remotes/trunk
This put me much closer to eliminating svn from my daily process.
