git-svn trap for young players

Dec 03, 2008 09:53

If you make changes in your local git repository, then want to commit them to the Subversion repository, here's the way to do it:



1) git commit … - make sure your git working directory is "clean" with no uncommitted changes

2) git svn fetch - get the latest updates from Subversion. These only exist in the commit tree, not in your working copy. To get the changes into your working copy:

3) git svn rebase - to merge the Subversion changes into your local working copy

4) Resolve merge conflicts

5) git commit … - again, make sure your git working directory is "clean"

5a) Make sure you repeat steps 2-5 until there are no new changes brought down by git svn fetch.

6) git svn dcommit - this is the part that actually commits all of your changes to the upstream

If you don't follow the steps of this little dance correctly, you'll end up with warnings like this:

Merge conflict during commit: Your file or directory
'git/path/to/some/committed/file' is probably out-of-date: The
version resource does not correspond to the resource within the
transaction. Either the requested version resource is out of date
(needs to be updated), or the requested version resource is newer
than the transaction root (restart the commit).

The way to get out of that mess is to get back into the dance. Fetch, rebase, resolve, commit. Do not attempt to git svn dcommit until you have no outstanding changes in the upstream, no uncommitted changes in the working copy, and git svn rebase tells you there are no outstanding changes to merge.

I would recommend the article Synchronizing Repositories - Daya Bay as a primer for folks just getting into the git-svn scene.

git, subversion

Previous post Next post
Up