Git SVN versus Empty Directories

Git only tracks files. SVN also tracks directories. So if you are using git svn to interoperate between the two, there can be problems. If you delete a bunch of directories in a git commit and then dcommit that change up to SVN, the directories themselves will not be deleted from the SVN repository.

You can work around this problem by including the --rmdir switch on dcommit. This will delete any empty directories upon commit. If you do not care about empty directories, this works fine. But if you do care about empty directories (maybe a build script depends upon their existence), there does not appear to be a satisfactory prepackaged solution.

JIRA vs. Cookies

Under some circumstances, I have seen JIRA fields disappear completely from pages, along with the "show" buttons that are supposed to reveal them.  The solution is to clear your cookies.

H2

 H2 is the successor to Hypersonic DB, by the original author.

Git SVN versus SVN relocate

git svn does not have an explicit feature to deal with the relocation of a Subversion repository.  I'm not sure if this was a good design choice, but git svn writes the SVN repository URL and revision number into each commit.  git svn seems to get confused if you just do the obvious thing and change all occurrences of the old repository URL to the new one.

You seem to have two choices.  The first is to point git svn to the new repository, but tell it to rewrite the URL when storing it in git.  This is accomplished easily by adding a rewriteRoot directive to the appropriate svn-remote section of the Git config:

[svn-remote "svn"]
	url = new-svn-url
	rewriteRoot = old-svn-url

Note that the log entries for any future commits in the Subversion repository will use the old (rewritten) name, so you must be willing to accept that.

If you want to update all of the URLs, the process is a bit more complex, something like:

# rewrite all of the commit comments
git filter-branch --msg-filter 'sed "s.git-svn-id: old-svn-url.git-svn-id: new-svn-url."' \
  $(git for-each-ref --format "%(refname)")

# blow away the cached SVN information
rm -rf .git/svn

# change all of the old SVN URLs in the config to the new URL
cat .git/config | sed 's.old-svn-url.new-svn-url.g' >.git/config2
mv .git/config2 .git/config

# rebase
git svn rebase

# delete the old objects that were rewritten
# rm -rf .git/refs/original
# git gc

I actually tried this as an experiment.  The message rewriting took a fair bit of time, but nowhere near the length of time for a clone from scratch.  It all went well but the next time I did a git svn fetch, it took longer than I was willing to wait before killing it.  Also, the cached SVN information did not appear to be rebuilt correctly.  Maybe I should have waited longer (than an hour or so)?  And of course all of the SHAs changed because I had rewritten the commit logs.

I think the first solution is better.  In future I will probably build any git svn repositories using a generic (rewritten) URL for the source right out of the box.  Maybe an URN is better.

This issue seems to cause quite a bit of angst in the git/SVN community.  Various workarounds have been proposed.  See, for example, GitSvnSwitch.