CODEWITHSUNDEEP
gitsvngit-svn
user4388759
user4388759

Reputation: 111

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?

Upvotes: 1

Views: 123

Answers (2)

user4388759
user4388759

Reputation: 111

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.

Upvotes: 1

amavroudakis
amavroudakis

Reputation: 2362

In general one should avoid adding dlls and binaries (especially if they are updated frequently) to git repositories. Doing so will blow up the size of the repository and as the history of the whole repository is also stored locally on the developer's PC it can make initial clones of the repo painful and time consuming.

Maybe this is not what you want to hear or maybe you cant (for reasons that you cant control do this) but here is my advise:

3rd party dlls should be referenced via NuGet packages. If you look ito NuGet it will allow you to restore the references of your projects on a clean checkout so there is no need to commit binaries to your repo. For details look to the docs in nuget.org

For internal projects you should examine why you are referencing them as dlls and not as projects. If a project is used only by one application then it should be referenced as a project (project reference in Visual Studio) and not as an assembly. If this project is referenced by more than one application the you should consider merging these solutions into one Visual Studio solution especially if these applications share more than one projects. If this is not desirable then you should make this project its own solution (or maybe group more projects liek this into one solution) and have your CI server build it and produce NuGets for you to reference in your main application project/solution via a local Nuget server or file system share. Teh idea is that you should treat internal reusable projects in the same way as you treat external (like log4net) when it comes to referencing them.

It takes more work but that is the right way and you have a nicely decoupled system that does not commit a single binary into the repository.

Obviously the above is just an outline of the overall ide and the devil is in the detail, but I hope I gave you enough info to take this further if you are interested and you think is a good idea.

Upvotes: 2

Related Questions