Question

Where I work, we use a slightly unconventional svn repo layout for projects. It looks like this:

project/
  branches/
  tags/
  trunk/
  utils/

We’re a pretty small company, and most of our projects are relatively small. Each developer working on a project usually has a checkout of the whole repo, and there are some post-commit hooks that prevent changes being made to multiple branches at once. The utils folder contains some scripts that are useful for each project, including things like automating HOSTS and apache vhost directive creation for a developers local machine when the repo is first pulled, a few svn shortcuts, and some project-specific stuff.

This layout works pretty well for us.

Now, I’d like to use git-svn, but I’m having trouble figuring out how the addition of that utils folder that is accessible to a developer regardless of what branch they’re working on would translate into git.

The only possible way to deal with this that I’ve been able to figure out would be to git svn clone the whole repo, and then set up some aliases for git svn fetch --ignore-paths so that if I’m working on a specific branch, I wouldn’t be fetching changes from other branches, and then create local topic branches for each remote branch.

The downside of doing this is mostly having to set up those aliases — it’s a somewhat ugly solution, in my opinion — but it seems like it should work at least. As for using the branch detection/integration capabilities of git-svn, I don’t think that it could work here because checking out a branch is “destructive”, and that utils folder exists at the top level of the repo.

So, is there either a better way of restricting git-svn stuff to the directory that represents the current branch, or a cleaner way of handling this scenario in general?

Answer 1

I don’t have an answer for the main part of your question, but I might have one for your ‘having to set up aliases with –ignore-paths’ problem.

Where I work, instead of doing a git svn clone and getting everything, we do the following:

git svn init <Svn repo url> -T trunk -b branches --ignore-paths '(ignore1|ignore2)'

then we fetch from a reasonable point in the history:

git svn fetch -r 12345:HEAD

That way we get a shallow, narrow clone of the svn repository.

Then in the future we just need to do:

git svn fetch

to update the git svn repo before doing git rebase and git svn dcommit to push back up to the svn repo.