CODEWITHSUNDEEP
gitgit-svn
jdd
jdd

Reputation: 4336

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

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?

Upvotes: 1

Views: 933

Answers (3)

javabrett
javabrett

Reputation: 7618

Latest answer ever, but ...

I would council against running git svn against your SVN repo-root with the -s switch or equivalents, unless you really know this is what you want. This will result in a very "un-git" eventual repository, where code from your different branches are duplicated within every Git branch you ever create. Shudder.

What you want to do is to use the -s standard-layout option, and let git svn do beautiful work creating proper branches and their history.

About utils? It's location and your description of it suggest that it is an independently-versioned structure. Changes in it are independent of what occurs on each branch, otherwise it would be stored per-branch. To bring it into Git, you should firstly create a separate Git clone of just this directory. You then have a couple of choices: you can a) decide that it is now kept per-branch in Git, and just check it into the HEAD of each branch you care about going-forward. You may need to fix and retag old/important tags. Or b), just bring it into Git as an independently-versioned Git sub-module, which is what it appears to be. Then you can have it in every branch, but commit to it centrally. You would of course need to update your scripts to account for the new location ./utils not ../utils.

Upvotes: 0

Mark Booth
Mark Booth

Reputation: 7944

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.

Upvotes: 1

Peter Bratton
Peter Bratton

Reputation: 6408

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!

Upvotes: 1

Related Questions