Search code examples
gitsvngit-svn

Git Svn Migration - Handling directory of binaries

So, in the course of attempting to migrate our company repo from SVN to Git, I've run into the following issue -

Currently, we have a "lib" folder in our repository containing a variety of DLLs from various internal projects (as well as third-party DLLs, but that's an easier issue). It is currently possible to simply build an internal project, commit the relevant build output, and then update the "lib" folder to get the new version of the DLL. This is accomplished via the "svn:externals" property on the "lib" folder, which has pointers to the build output directories of the various projects.

So if we want lib to have project Foo under the name FooLib, we would have the line 

^/path/to/foo/in/svn/build/Release FooLib

in lib's svn:externals property.

I'm aware that this is not the optimal way to do things, but it's not currently advisable to change it. I'm trying to replicate this workflow in Git, and I'm not completely sure my idea for doing so is right, so I'd like advice on whether it is and what a better way might be. For the record, our developers are (obviously, from my talk of DLLs) running Windows, while the git server is Linux.

  1. Create a "lib" repository with the same structure as our current one.
  2. Every project that has a dll in "lib" will include "lib" as a submodule (or subtree? I understand there's a difference, but I haven't managed to get into it yet).
  3. Write a post-receive hook for every such project that checks if build output was pushed, and if so, copies it to the "lib" submodule and pushes.

Ideally, I'd also like the "lib" submodule to stay server-side and not get pulled down by clone requests, as it would essentially be an implementation detail to users (currently we just checkout "lib" to a fixed directory on our hard drives and update it constantly, which would be equally simple with Git).

Is this idea correct? Hopelessly complex? Am I missing something? Is there a better way to solve this issue?

Solution

  • For anyone else who is stuck unable to implement tolism7's advice (which is indeed best practice), I ended up going with what I mentioned in my question - I wrote a git hook for the post-recieve event (so as not to interfere with pushing to the repo), that checked whether specified DLLs in the repo were included in the commit. If so, the new DLL was pushed to our special "system" repo. If necessary, I imagine you could also then include that repo as a submodule, but we're used to having a "magic dir" with all dlls at a fixed location on the system, so this lets us duplicate that.