Using git-svn with an unconventional repo layout that includes a directory that should be accessible to any branches

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 started to write out a response on how to expose utils/ as a branch area to git svn, and then realized that it isn't really a branch at all; its a different project altogether. I.E., the code under this tree does not share any ancestry with code under the branches, tags, and trunk trees. Since everyone is checking out the whole repository, I wonder how merges are going for you, but that's another story.

If you use git-svn here, you can probably get away with treating this repo like a standard repo. You'll have the whole repository, but you'll only be able to work with one branch at a time (sort of the behavior it seems your commit hooks is enforcing). As for the utils directory, you might consider creating a separate git svn repo just for that. After all, you aren't merging changes into and out of that area anyway, so you really wouldn't lose anything other than needing to update another WC periodically.

Good luck!